[pgpool-hackers: 3532] Re: Refactoring running mode in Pgpool-II

[Muhammad Usama]

On Wed, Mar 4, 2020 at 11:50 AM Tatsuo Ishii <ishii at sraoss.co.jp> wrote:

> > Yes, Its would be a nice feature and it would create more clarity in
> > configuration. Few comments/suggests.
> > 1.
> > To me "running_mode" seems bit generic, and it might be confusing whether
> > its is something related to how pgpool application was started ( like we
> > have pgpool -m smart/fast/etc ),
> > We might have same feature of 'pgpool start' as well (
> > headless/light/integrated etc. )
> >
> > Instead of 'running_mode' we can have 'replication_setup' or
> > 'replication_setup_mode'  with following value:
> > streaming
> > logical
> > native
> > slony
> > raw
>
> Makes sense. I prefer 'replication_setup_mode'.
>

 replication_setup_mode seems good, I am also thinking about something like
"backend_clustering_mode" or "backend_clustering_setup"
What do you think?

>
> > 2.
> > Just an idea, we should develop this in extensibility in mind. In
> feature,
> > if we have some new kind of replication mode, pgpool should be able to
> > accommodate it with minimum changes ( or my be user can provide their own
> > replication mode somehow, like we have memcached extensibility )
>
> That's an interesting idea. Maybe something like *preload_libraries in
> PostgreSQL?
>

That's an interesting idea but we should also keep a close eye on the
performance impact of such a change

Thanks
Best regards
Muhammad Usama


> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.sraoss.jp/pipermail/pgpool-hackers/attachments/20200304/ef20e301/attachment-0001.html>