From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | Peter Smith <smithpb2250(at)gmail(dot)com>, "shiy(dot)fnst(at)fujitsu(dot)com" <shiy(dot)fnst(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Force streaming every change in logical decoding |
Date: | 2022-12-07 07:51:04 |
Message-ID: | CAA4eK1KmyuGHmcm+Su9NGbz=vke5bUowEoPOwFhEBYtGximzeQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Dec 7, 2022 at 10:55 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Wed, Dec 7, 2022 at 12:55 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> >
>
> > On one side having separate GUCs for publisher and subscriber seems to
> > give better flexibility but having more GUCs also sometimes makes them
> > less usable. Here, my thought was to have a single or as few GUCs as
> > possible which can be extendible by providing multiple values instead
> > of having different GUCs. I was trying to map this with the existing
> > string parameters in developer options.
>
> I see your point. On the other hand, I'm not sure it's a good idea to
> control different features by one GUC in general. The developer option
> could be an exception?
>
I am not sure what is the best thing if this was proposed as a
non-developer option but it seems to me that having a single parameter
for publisher/subscriber, in this case, can serve our need for
testing/debugging. BTW, even though it is not a very good example but
we use max_replication_slots for different purposes on the publisher
(the limit for slots) and subscriber (the limit for origins).
--
With Regards,
Amit Kapila.
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-12-07 07:56:41 | Generating code for query jumbling through gen_node_support.pl |
Previous Message | Pavel Luzanov | 2022-12-07 07:48:49 | Re: add \dpS to psql |