[pgpool-hackers: 3815] Re: Proposal: language cleanup in Pgpool-II

Wed Sep 16 16:28:36 JST 2020

Hi Tatsuo Ishii,
Thanks for review. Please see comments inline:

On Wed, Sep 16, 2020 at 3:33 AM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> Hi Umar,
>
> Thank you for the patch! That must be a hard work.
>
> Here are some comments:
>
> (1) I got some whitespace errors while applying patches.
>
> ../language_fixes/v1-001-blackwhite-to-redgreen.diff:978: trailing
> whitespace.
>      Add new parameter <xref linkend="guc-red-query-pattern-list"> to
> enable
> ../language_fixes/v1-002-Watchdog-master-leader.diff:4417: trailing
> whitespace.
> # test if leader and backend goes down at same time Pgpool-II behaves as
> expected
> ../language_fixes/v1-007-follow_master-and-recovery-and-misc.diff:13476:
> trailing whitespace.
>
> ../language_fixes/v1-007-follow_master-and-recovery-and-misc.diff:13488:
> trailing whitespace.
>
> warning: 4 lines add whitespace errors.
>
> I will fix them in next patch.

> > Hi Team,
> > Attached patches for inclusive language for pgpool. please find few
> details
> > about each patch bellow:
> > v1-001-blackwhite-to-redgreen
> >   Replace black with red and white with green for white_function_list,
> > black_function_list, black_query_pattern, white_memqcache_table_list,
> > black_memqcache_table_list
>
> Replacing to red and green is a little bit confusing to me. What
> about denylist/allowlist? It's suggested by Linux.
>
> Yes, I read few Linux related articles and few other sources
too. denylist/allowlist is used for decision where we either allow or deny.
In our case, based on mutability factor we decide whether we should send
query to primary or standby. So in-fact we are not blocking queries.
IMO we can use
1. deny/allow ( e.g allow_function_list, deny_function_list,
allow_query_pattern, allow_memqcache_table_list, deny_memqcache_table_list)
?
2. or descriptive term like mutable/immutable & safe/unsafe based on pgpool
usage ( e.g. mutable_function_list, immutable_function_list,
safe_query_pattern, safe_memqcache_table_list, unsafe_memqcache_table_list
) ?

> v1-002-Watchdog-master-leader
> >    Replace master to 'leader' for 'master' watchdog nodes
>
> Sounds reasonable choice to me.
>
> > v1-003-ALWAYS_MASTER-to-ALWAYS_PRIMARY
> >   Replace backend_flagx option 'ALWAYS_MASTER' with 'ALWAYS_PRIMARY'
>
> Sounds good to me.
>
> > v1-004-relcache_query_target--master-to-primary
> >    Replace relcache_query_target option 'master' to 'primary'
>
> Sounds good to me.
>
> > v1-005-master-slave-to-primarystandby
> >    Replace Master/Slave with Primary/Secondary
>
> I think we could replace "Master/Slave mode" to "Native replication
> mode".
>
> Using "Primary" as the replacemnet for "Master" sounds is confusing as
> there's "Primary" in the streaming replication mode.
>
> I will use Native Replication  mode in next patch.

> > v1-006-masterslave-to-mainreplica
> >    Replace Master Node with Main node ( node id with 0 or youngest live )
> >    Couldn't translate with primary/leader as they were already used in
> > different context
>
> Sounds good to me.
>
> > v1-007-follow_master-and-recovery-and-misc
> >    Replace follow_master with follow_primary with parameters replaced
> with
> > new/old master with new/old main.
> >    Replace some remaining occurrences of master with primary/main/leader
>
> Sounds good to me.
>
> > In the above patches I didn't change older releases notes ( except for
> some
> > links so they don't break and point to new terminology), history, TODO
> and
> > Japanese Doc string.
>
> Sounds good to me. (I will take care of Japanese Doc string).
>
> > Postmaster ( It's used around 150 times ) and very few other occurrences
> of
> > 'master' are still present.
>
> No objection from me.
>
> > There are alot of inter-dependent terminologies and so I might have
> missed
> > something. Looking at them as a whole makes some sense, changing one term
> > might lead to inconsistency in some other areas.
> > I tried to come up with the above terminologies, just to start
> > conversation. Feel free to share feedback and comments.
>
> Thanks.
>
> > Regards
> > Umar Hayat
> >
> >
> > On Fri, Sep 4, 2020 at 8:03 AM Umar Hayat <m.umarkiani at gmail.com> wrote:
> >
> >> Hi Tatsuou Ishii,
> >> Yes I'm planning for 4.2 and work is in progress, I will send patches in
> >> the upcoming week.
> >>
> >> Regards
> >> Umar Hayat
> >>
> >> On Thu, Sep 3, 2020 at 5:59 AM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:
> >>
> >>> Hi Umar,
> >>>
> >>> Now that we are getting closer to release Pgpool-II 4.2, I would like
> >>> to know if you wish to bring your work into 4.2 or not. If you wish,
> >>> can you please tell us the time line for the patch?
> >>>
> >>> > On Fri, Jul 24, 2020 at 4:33 PM Tatsuo Ishii <ishii at sraoss.co.jp>
> >>> wrote:
> >>> >
> >>> >> > Hi Hackers,
> >>> >> > Recently PG community did a language clean up ( to make it more
> >>> >> inclusive )
> >>> >> > for Server, including docs and code (see here
> >>> >> > <
> >>> >>
> >>>
> https://www.postgresql.org/message-id/20200615182235.x7lch5n6kcjq4aue@alap3.anarazel.de
> >>> >> >).
> >>> >> > Most changes were related to renaming "slave" and "master"
> >>> terminologies.
> >>> >> > Do we have any plans to make such changes to make pgpool
> consistent
> >>> with
> >>> >> > Server as well as in general Pgpool specific things ?
> >>> >> > If we do have a plan, it would need multiple patches as it would
> >>> affect
> >>> >> > docs, code and configuration and samples.
> >>> >> > Let me know suggestions and thoughts and I can work on this.
> >>> >>
> >>> >> It seems the discussion is still on going? I mean it has not been
> >>> >> committed yet?
> >>> >>
> >>> >>
> >>> >>
> >>>
> https://www.postgresql.org/message-id/flat/20200615182235.x7lch5n6kcjq4aue%40alap3.anarazel.de
> >>> >>
> >>> >> Discussion is going on for two pending point which are not part of
> >>> patches
> >>> > ( postmaster & master branch) and one WIP patch(multi-master), rest
> of
> >>> the
> >>> > 7 patches for that thread are committed.
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=229f8c219f8fffacc253eca6023eab10a16eb009
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5e7bbb528638c0f6d585bab107ec7a19e3a39deb
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=e07633646a22734e85d7fc58a66855f747128e6b
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=9e101cf60612f4be4f855d7393531900c2986a55
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=09dfd430118f1fadf52a782db5ee161b1eb16337
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=7c89f8a5b810d10dae300ec58ea7d70024e9123e
> >>> >
> >>>
> https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=a9a4a7ad565b136cbee735d4bb505d98d06da522
> >>> >
> >>> >
> >>> >> The topic has not been discussed yet in pgpool-hackers, but I
> >>> >> personally think we need to do something soon or later anyway. My
> >>> >> concern is that that might require user-visible changes like:
> >>> >>
> >>> >> master
> >>> >> slave
> >>> >> white_function_list
> >>> >> black_function_list
> >>> >> black_query_pattern_list
> >>> >> white_memqcache_table_list
> >>> >> black_memqcache_table_list
> >>> >> follow_master_command
> >>> >> relcache_query_target = master
> >>> >> [maybe more...]
> >>> >>
> >>> >> Is it possible for you to come with a proposal for this so that
> pgpool
> >>> >> hackers could start discussion?
> >>> >>
> >>> >> Best regards,
> >>> >> --
> >>> >> Tatsuo Ishii
> >>> >> SRA OSS, Inc. Japan
> >>> >> English: http://www.sraoss.co.jp/index_en.php
> >>> >> Japanese:http://www.sraoss.co.jp
> >>> >
> >>> >
> >>> > Sure, I will create proposal for different sections and patches to
> >>> discuss
> >>> > it further.
> >>> >
> >>> > Thanks
> >>> > Umar Hayat
> >>>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20200916/237c7753/attachment.html>