Re: POC: enable logical decoding when wal_level = 'replica' without a server restart

On Mon, Jun 30, 2025 at 11:16 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Thu, Jun 26, 2025 at 5:50 PM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Wed, Jun 25, 2025 at 12:20 PM Bertrand Drouvot
> > <bertranddrouvot.pg@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Jun 25, 2025 at 09:15:04AM +0530, shveta malik wrote:
> > > > On Wed, Jun 25, 2025 at 9:12 AM shveta malik <shveta.malik@gmail.com> wrote:
> > > > >
> > > > > On Tue, Jun 24, 2025 at 2:12 PM Bertrand Drouvot
> > > > > <bertranddrouvot.pg@gmail.com> wrote:
> > > > > >
> > > > > > 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. ...
> > >
> > > Agree.
>
> Agreed.
>
> > >
> > > > > > 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?
> > >
> > > Since it will be possible to switch back to logical without a restart I do
> > > think that it could make sense to avoid a new GUC. Unless there is a use case
> > > to keep the wal level to logical (outside of the "logical decoding from
> > > standby" context)?
> > >
> >
> > I don’t currently see a specific use case for this, but I’m somewhat
> > inclined to include the GUC because it can serve as a safety
> > mechanism. If issues arise with the new behavior, the GUC allows users
> > to revert to manually controlling wal_level. The GUC would only manage
> > the automatic aspect of the feature, where slot creation and deletion
> > internally adjust wal_level. But I don’t have a strong preference and
> > am open to omitting the GUC if others believe it is unnecessary.
>
> I think the new SQL API to enable the logical decoding would provide a
> new way for users who want to enable the logical decoding for standbys
> without creating a slot. With that, the user can enable/disable the
> logical decoding by calling the SQL function. Also, it's not a
> replacement of the current usage (i.e., changing wal_level with
> restarting the server). The GUC parameter we're discussing sounds like
> a way to serve the current behavior that allows users to
> enable/disable the logical decoding only with restarting the server.
> I'm not sure if there are users who want to disable the new behavior
> and use only the current behavior. I think we can focus on the new API
> and automatic behavior at this stage. If we find out there are certain
> use cases, we can revisit this idea.
>

Okay, sounds good to me.

thanks
Shveta