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

On Thu, Jun 26, 2025 at 5:50 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Wed, Jun 25, 2025 at 12:20 PM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)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(dot)malik(at)gmail(dot)com> wrote:
> > > >
> > > > On Tue, Jun 24, 2025 at 2:12 PM Bertrand Drouvot
> > > > <bertranddrouvot(dot)pg(at)gmail(dot)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.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com