On Sun, May 18, 2025 at 1:09 AM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > On Sat, May 10, 2025 at 7:08 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > Can we have a parameter like immediately_reserve in > > create_logical_slot API, similar to what we have for physical slots? > > We need to work out the details, but that should address the kind of > > use case you are worried about, unless I am missing something. > > Interesting idea. One concern in my mind is that in the use case I > mentioned above, users would need to carefully manage the extra > logical slot to keep the logical decoding active. The logical decoding > is deactivated on the standby as soon as users drop all logical slots > on the primary. >
Yes, but the same is true for a physical slot in the case of physical replication used via primary_slot_name parameter. > Also, with this idea of automatically increasing WAL level, do we want > to keep the 'logical' WAL level? If so, it requires an extra step of > creating a non-reserved logical slot on the primary in order for the > standby to activate the logical decoding. On the other hand, we can > also keep the 'logical' WAL level for the compatibility and for making > the logical decoding enabled without the coordination of WAL level > transition. Right, I also feel we should retain both ways to enable logical replication at least initially. Once we get some feedback, we may think of removing 'logical' as wal_level. > But wal_level GUC parameter would no longer tell the > actual WAL level to users when 'replica' + logical slots. > Right. > Is it > sufficient to provide a read-only GUC parameter, say > effective_wal_level showing the actual WAL level being used? > I am not so sure about how we want to communicate this to the user, but I guess to start with, this is a good idea. -- With Regards, Amit Kapila.
