<div dir="ltr">Hi Ishii, <div>Due to a recent commit, v2-005 failed in runtime.sgml file (and subsequent patches failed). Please find the attached v3-005 patch ( you can use other 6 patches from v2 ).</div><div><br></div><div>Regards</div><div>Umar Hayat</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 17, 2020 at 3:08 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp">ishii@sraoss.co.jp</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Umar,<br>
<br>
Thank you for the new version of patches. However when I git apply<br>
each patches against current master, some of them do not apply. Can<br>
you please rebase them?<br>
<br>
../language_fixes/v2-005-master-slave-to-native-replication.diff<br>
error: patch failed: doc/src/sgml/runtime.sgml:187<br>
error: doc/src/sgml/runtime.sgml: patch does not apply<br>
../language_fixes/v2-006-masterslave-to-mainreplica.diff<br>
error: patch failed: doc/src/sgml/loadbalance.sgml:27<br>
error: doc/src/sgml/loadbalance.sgml: patch does not apply<br>
error: patch failed: src/protocol/pool_process_query.c:3281<br>
error: src/protocol/pool_process_query.c: patch does not apply<br>
error: patch failed: src/protocol/pool_proto_modules.c:228<br>
error: src/protocol/pool_proto_modules.c: patch does not apply<br>
../language_fixes/v2-007-follow_master-and-recovery-and-misc.diff<br>
error: patch failed: doc.ja/src/sgml/failover.sgml:621<br>
error: doc.ja/src/sgml/failover.sgml: patch does not apply<br>
error: patch failed: doc/src/sgml/failover.sgml:475<br>
error: doc/src/sgml/failover.sgml: patch does not apply<br>
error: patch failed: doc/src/sgml/restrictions.sgml:127<br>
error: doc/src/sgml/restrictions.sgml: patch does not apply<br>
error: patch failed: src/main/pgpool_main.c:1596<br>
error: src/main/pgpool_main.c: patch does not apply<br>
error: patch failed: src/protocol/pool_process_query.c:83<br>
error: src/protocol/pool_process_query.c: patch does not apply<br>
<br>
> Hi Team,<br>
> Please find second version patches attached with updates suggested. Feel<br>
> free to comment if more improvements are needed.<br>
> <br>
> Regards<br>
> Umar Hayat<br>
> <br>
> <br>
> On Wed, Sep 16, 2020 at 1:42 PM Umar Hayat <<a href="mailto:m.umarkiani@gmail.com" target="_blank">m.umarkiani@gmail.com</a>> wrote:<br>
> <br>
>> Hi,<br>
>><br>
>> On Wed, Sep 16, 2020 at 1:28 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>> wrote:<br>
>><br>
>>> Hi Umar,<br>
>>><br>
>>> >> Replacing to red and green is a little bit confusing to me. What<br>
>>> >> about denylist/allowlist? It's suggested by Linux.<br>
>>> >><br>
>>> >> Yes, I read few Linux related articles and few other sources<br>
>>> > too. denylist/allowlist is used for decision where we either allow or<br>
>>> deny.<br>
>>> > In our case, based on mutability factor we decide whether we should send<br>
>>> > query to primary or standby. So in-fact we are not blocking queries.<br>
>>><br>
>>> That makes sense.<br>
>>><br>
>>> > IMO we can use<br>
>>> > 1. deny/allow ( e.g allow_function_list, deny_function_list,<br>
>>> > allow_query_pattern, allow_memqcache_table_list,<br>
>>> deny_memqcache_table_list)<br>
>>> > ?<br>
>>> > 2. or descriptive term like mutable/immutable & safe/unsafe based on<br>
>>> pgpool<br>
>>> > usage ( e.g. mutable_function_list, immutable_function_list,<br>
>>> > safe_query_pattern, safe_memqcache_table_list,<br>
>>> unsafe_memqcache_table_list<br>
>>> > ) ?<br>
>>><br>
>>> I like 2. What about:<br>
>>><br>
>>> black/white_function_list -> write_function_list, read_only_function_list<br>
>>> black_query_pattern -> primay_routing_query_pattern<br>
>>> black/white_memqcache_table_list -> cache_unsafe/cache_safe_table_list<br>
>>><br>
>>> Sounds good. I will send updated the patch with these terms.<br>
>><br>
>>> >> v1-002-Watchdog-master-leader<br>
>>> >> > Replace master to 'leader' for 'master' watchdog nodes<br>
>>> >><br>
>>> >> Sounds reasonable choice to me.<br>
>>> >><br>
>>> >> > v1-003-ALWAYS_MASTER-to-ALWAYS_PRIMARY<br>
>>> >> > Replace backend_flagx option 'ALWAYS_MASTER' with 'ALWAYS_PRIMARY'<br>
>>> >><br>
>>> >> Sounds good to me.<br>
>>> >><br>
>>> >> > v1-004-relcache_query_target--master-to-primary<br>
>>> >> > Replace relcache_query_target option 'master' to 'primary'<br>
>>> >><br>
>>> >> Sounds good to me.<br>
>>> >><br>
>>> >> > v1-005-master-slave-to-primarystandby<br>
>>> >> > Replace Master/Slave with Primary/Secondary<br>
>>> >><br>
>>> >> I think we could replace "Master/Slave mode" to "Native replication<br>
>>> >> mode".<br>
>>> >><br>
>>> >> Using "Primary" as the replacemnet for "Master" sounds is confusing as<br>
>>> >> there's "Primary" in the streaming replication mode.<br>
>>> >><br>
>>> >> I will use Native Replication mode in next patch.<br>
>>> ><br>
>>> >> > v1-006-masterslave-to-mainreplica<br>
>>> >> > Replace Master Node with Main node ( node id with 0 or youngest<br>
>>> live )<br>
>>> >> > Couldn't translate with primary/leader as they were already used<br>
>>> in<br>
>>> >> > different context<br>
>>> >><br>
>>> >> Sounds good to me.<br>
>>> >><br>
>>> >> > v1-007-follow_master-and-recovery-and-misc<br>
>>> >> > Replace follow_master with follow_primary with parameters replaced<br>
>>> >> with<br>
>>> >> > new/old master with new/old main.<br>
>>> >> > Replace some remaining occurrences of master with<br>
>>> primary/main/leader<br>
>>> >><br>
>>> >> Sounds good to me.<br>
>>> >><br>
>>> >> > In the above patches I didn't change older releases notes ( except<br>
>>> for<br>
>>> >> some<br>
>>> >> > links so they don't break and point to new terminology), history,<br>
>>> TODO<br>
>>> >> and<br>
>>> >> > Japanese Doc string.<br>
>>> >><br>
>>> >> Sounds good to me. (I will take care of Japanese Doc string).<br>
>>> >><br>
>>> >> > Postmaster ( It's used around 150 times ) and very few other<br>
>>> occurrences<br>
>>> >> of<br>
>>> >> > 'master' are still present.<br>
>>> >><br>
>>> >> No objection from me.<br>
>>> >><br>
>>> >> > There are alot of inter-dependent terminologies and so I might have<br>
>>> >> missed<br>
>>> >> > something. Looking at them as a whole makes some sense, changing one<br>
>>> term<br>
>>> >> > might lead to inconsistency in some other areas.<br>
>>> >> > I tried to come up with the above terminologies, just to start<br>
>>> >> > conversation. Feel free to share feedback and comments.<br>
>>> >><br>
>>> >> Thanks.<br>
>>> >><br>
>>> >> > Regards<br>
>>> >> > Umar Hayat<br>
>>> >> ><br>
>>> >> ><br>
>>> >> > On Fri, Sep 4, 2020 at 8:03 AM Umar Hayat <<a href="mailto:m.umarkiani@gmail.com" target="_blank">m.umarkiani@gmail.com</a>><br>
>>> wrote:<br>
>>> >> ><br>
>>> >> >> Hi Tatsuou Ishii,<br>
>>> >> >> Yes I'm planning for 4.2 and work is in progress, I will send<br>
>>> patches in<br>
>>> >> >> the upcoming week.<br>
>>> >> >><br>
>>> >> >> Regards<br>
>>> >> >> Umar Hayat<br>
>>> >> >><br>
>>> >> >> On Thu, Sep 3, 2020 at 5:59 AM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a>><br>
>>> wrote:<br>
>>> >> >><br>
>>> >> >>> Hi Umar,<br>
>>> >> >>><br>
>>> >> >>> Now that we are getting closer to release Pgpool-II 4.2, I would<br>
>>> like<br>
>>> >> >>> to know if you wish to bring your work into 4.2 or not. If you<br>
>>> wish,<br>
>>> >> >>> can you please tell us the time line for the patch?<br>
>>> >> >>><br>
>>> >> >>> > On Fri, Jul 24, 2020 at 4:33 PM Tatsuo Ishii <<a href="mailto:ishii@sraoss.co.jp" target="_blank">ishii@sraoss.co.jp</a><br>
>>> ><br>
>>> >> >>> wrote:<br>
>>> >> >>> ><br>
>>> >> >>> >> > Hi Hackers,<br>
>>> >> >>> >> > Recently PG community did a language clean up ( to make it<br>
>>> more<br>
>>> >> >>> >> inclusive )<br>
>>> >> >>> >> > for Server, including docs and code (see here<br>
>>> >> >>> >> > <<br>
>>> >> >>> >><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://www.postgresql.org/message-id/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de" rel="noreferrer" target="_blank">https://www.postgresql.org/message-id/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de</a><br>
>>> >> >>> >> >).<br>
>>> >> >>> >> > Most changes were related to renaming "slave" and "master"<br>
>>> >> >>> terminologies.<br>
>>> >> >>> >> > Do we have any plans to make such changes to make pgpool<br>
>>> >> consistent<br>
>>> >> >>> with<br>
>>> >> >>> >> > Server as well as in general Pgpool specific things ?<br>
>>> >> >>> >> > If we do have a plan, it would need multiple patches as it<br>
>>> would<br>
>>> >> >>> affect<br>
>>> >> >>> >> > docs, code and configuration and samples.<br>
>>> >> >>> >> > Let me know suggestions and thoughts and I can work on this.<br>
>>> >> >>> >><br>
>>> >> >>> >> It seems the discussion is still on going? I mean it has not<br>
>>> been<br>
>>> >> >>> >> committed yet?<br>
>>> >> >>> >><br>
>>> >> >>> >><br>
>>> >> >>> >><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://www.postgresql.org/message-id/flat/20200615182235.x7lch5n6kcjq4aue%40alap3.anarazel.de" rel="noreferrer" target="_blank">https://www.postgresql.org/message-id/flat/20200615182235.x7lch5n6kcjq4aue%40alap3.anarazel.de</a><br>
>>> >> >>> >><br>
>>> >> >>> >> Discussion is going on for two pending point which are not part<br>
>>> of<br>
>>> >> >>> patches<br>
>>> >> >>> > ( postmaster & master branch) and one WIP patch(multi-master),<br>
>>> rest<br>
>>> >> of<br>
>>> >> >>> the<br>
>>> >> >>> > 7 patches for that thread are committed.<br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=229f8c219f8fffacc253eca6023eab10a16eb009" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=229f8c219f8fffacc253eca6023eab10a16eb009</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5e7bbb528638c0f6d585bab107ec7a19e3a39deb" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5e7bbb528638c0f6d585bab107ec7a19e3a39deb</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e07633646a22734e85d7fc58a66855f747128e6b" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e07633646a22734e85d7fc58a66855f747128e6b</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e101cf60612f4be4f855d7393531900c2986a55" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e101cf60612f4be4f855d7393531900c2986a55</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=09dfd430118f1fadf52a782db5ee161b1eb16337" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=09dfd430118f1fadf52a782db5ee161b1eb16337</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7c89f8a5b810d10dae300ec58ea7d70024e9123e" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7c89f8a5b810d10dae300ec58ea7d70024e9123e</a><br>
>>> >> >>> ><br>
>>> >> >>><br>
>>> >><br>
>>> <a href="https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a9a4a7ad565b136cbee735d4bb505d98d06da522" rel="noreferrer" target="_blank">https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a9a4a7ad565b136cbee735d4bb505d98d06da522</a><br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> >> The topic has not been discussed yet in pgpool-hackers, but I<br>
>>> >> >>> >> personally think we need to do something soon or later anyway.<br>
>>> My<br>
>>> >> >>> >> concern is that that might require user-visible changes like:<br>
>>> >> >>> >><br>
>>> >> >>> >> master<br>
>>> >> >>> >> slave<br>
>>> >> >>> >> white_function_list<br>
>>> >> >>> >> black_function_list<br>
>>> >> >>> >> black_query_pattern_list<br>
>>> >> >>> >> white_memqcache_table_list<br>
>>> >> >>> >> black_memqcache_table_list<br>
>>> >> >>> >> follow_master_command<br>
>>> >> >>> >> relcache_query_target = master<br>
>>> >> >>> >> [maybe more...]<br>
>>> >> >>> >><br>
>>> >> >>> >> Is it possible for you to come with a proposal for this so that<br>
>>> >> pgpool<br>
>>> >> >>> >> hackers could start discussion?<br>
>>> >> >>> >><br>
>>> >> >>> >> Best regards,<br>
>>> >> >>> >> --<br>
>>> >> >>> >> Tatsuo Ishii<br>
>>> >> >>> >> SRA OSS, Inc. Japan<br>
>>> >> >>> >> English: <a href="http://www.sraoss.co.jp/index_en.php" rel="noreferrer" target="_blank">http://www.sraoss.co.jp/index_en.php</a><br>
>>> >> >>> >> Japanese:<a href="http://www.sraoss.co.jp" rel="noreferrer" target="_blank">http://www.sraoss.co.jp</a><br>
>>> >> >>> ><br>
>>> >> >>> ><br>
>>> >> >>> > Sure, I will create proposal for different sections and patches<br>
>>> to<br>
>>> >> >>> discuss<br>
>>> >> >>> > it further.<br>
>>> >> >>> ><br>
>>> >> >>> > Thanks<br>
>>> >> >>> > Umar Hayat<br>
>>> >> >>><br>
>>> >> >><br>
>>> >><br>
>>><br>
>><br>
</blockquote></div>