On Thu, Jun 26, 2025 at 5:50 PM shveta malik <shveta.ma...@gmail.com> wrote: > > On Wed, Jun 25, 2025 at 12:20 PM Bertrand Drouvot > <bertranddrouvot...@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.ma...@gmail.com> > > > wrote: > > > > > > > > On Tue, Jun 24, 2025 at 2:12 PM Bertrand Drouvot > > > > <bertranddrouvot...@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. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
