Re: Force streaming every change in logical decoding
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Peter Smith <smithpb2250@gmail.com>,
"shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-07T07:51:04Z
Lists: pgsql-hackers
On Wed, Dec 7, 2022 at 10:55 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > On Wed, Dec 7, 2022 at 12:55 PM Amit Kapila <amit.kapila16@gmail.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.
Commits
-
Add 'logical_decoding_mode' GUC.
- 5de94a041ed7 16.0 landed
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited