Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
От | shveta malik |
---|---|
Тема | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart |
Дата | |
Msg-id | CAJpy0uC6zz3xgMgsbSBtt2ue9tE1TsUJGXNeoDSpB6E4pD6s8Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: enable logical decoding when wal_level = 'replica' without a server restart (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
Список | 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 по дате отправления: