On Wed, Jun 25, 2025 at 9:12 AM shveta malik <shveta.ma...@gmail.com> wrote: > > On Tue, Jun 24, 2025 at 2:12 PM Bertrand Drouvot > <bertranddrouvot...@gmail.com> wrote: > > > > Hi, > > > > On Tue, Jun 24, 2025 at 12:13:32AM +0900, Masahiko Sawada wrote: > > > On Mon, Jun 23, 2025 at 7:01 PM Bertrand Drouvot > > > <bertranddrouvot...@gmail.com> wrote: > > > > > > > > Hi, > > > > > > > > On Mon, Jun 23, 2025 at 05:10:37PM +0900, Masahiko Sawada wrote: > > > > > On Thu, Jun 19, 2025 at 6:00 PM Bertrand Drouvot > > > > > <bertranddrouvot...@gmail.com> wrote: > > > > > > > > > > > > - pg_activate_logical_decoding() is needed only if there is not > > > > > > already a logical > > > > > > slot on the primary > > > > > > - the drop requires the user to think twice if this is the last > > > > > > logical slot > > > > > > - we don't ask the user to create a logical slot if he does not > > > > > > want to use it > > > > > > on the primary > > > > > > > > > > > > Thoughts? > > > > > > > > > > If there is no logical slot on the primary, how can the user disable > > > > > logical decoding that has been enabled via > > > > > pg_activate_logical_decoding()? > > > > > > > > I was thinking to keep the pg_deactivate_logical_decoding() API proposed > > > > in this thread. > > > > > > Okay. One approach that combines your idea and Shveta's idea is: > > > > > > - a special (empty) logical slot with the reserved slot name can be > > > created and deleted only by SQL functions, > > > pg_activate_logical_decoding() and pg_deactivate_logical_decoding(). > > > - this special slot cannot be used by logical decoding. > > > - effective_wal_level is increased and decreased when creating and > > > dropping a slot (i.e., either a normal logical slots or the special > > > logical slot). > > > > Yeah, I think that sounds reasonable and that would avoid users to use > > the slot created with immediately_reserve set to false by mistake. > > > > +1. > I think we do need to provide 'immediately_reserve' as a new argument > now for logical slots creation. If the slot is a special one with a > reserved name, it can internally be created with WALs not reserved for > our purpose. >
One correction here. I think we do NOT need to provide 'immediately_reserve' as a new argument now for logical slots creation. ... > > > > You mean a GUC to both automaticly set effective_wal_level to logical > > > > at slot creation > > > > and also decrease effective_wal_level to replica if last replication > > > > slot is dropped? > > > > > > What I imagined was to control only the decreasing behavior that could > > > be more problematic than the increase case. But it might be rather > > > confusing (e.g., what if we turn off that behavior and restart the > > > server?). > > > > Right...So not sure we need such a GUC. What about always behave with the > > automatic behavior? > > > > Does it make sense to provide a GUC which will have the default set to > automatic but if the user is not interested or having some issues with > new behaviour, he can switch off the GUC, making the new functions > no-op as well? > In absence of such a GUC, users will have absolutely no way to switch > back to old behaviour. Will that be okay? > > thanks > Shveta
