Re: POC: enable logical decoding when wal_level = 'replica' without a server restart - Mailing list pgsql-hackers

From shveta malik
Subject Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Date
Msg-id CAJpy0uC6zz3xgMgsbSBtt2ue9tE1TsUJGXNeoDSpB6E4pD6s8Q@mail.gmail.com
Whole thread Raw
In response to Re: POC: enable logical decoding when wal_level = 'replica' without a server restart  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
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.
>
> > > > 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.

thanks
Shveta



pgsql-hackers by date:

Previous
From: Dean Rasheed
Date:
Subject: Re: MERGE docs: indentation in synopsis section
Next
From: Tomas Vondra
Date:
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view