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

On Sat, May 10, 2025 at 7:08 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Sat, May 10, 2025 at 1:05 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> >
> > On Sat, May 10, 2025 at 12:00 AM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > >
> > > Right, but to an extent, this is also similar to having a requirement
> > > of a logical slot on the primary. Now, it seems to me that the point
> > > you are trying to make is that to allow logical decoding on standby,
> > > it is okay to ask users to use pg_activate_logical_decoding() on
> > > primary, but it would be inconvenient to ask them to have a logical
> > > slot on primary instead. If my understanding is correct, then why do
> > > you think so? We recommend that users have a physical slot on primary
> > > and use it via primary_slot_name on standby to control resource
> > > removal, so why can't we ask them to have a logical slot on primary to
> > > allow logical decoding on standby?
> >
> > I was thinking of a simple use case where users do logical decoding
> > from the physical standby. That is, the primary has a physical slot
> > and the standby uses it via primary_slot_name, and the subscriber
> > connects the standby server for logical replication with a logical
> > slot on the standby. In this case, IIUC we need to require users to
> > create a logical slot on the primary in order just to increase WAL
> > level to 'logical', but it doesn't make sense to me. No one is going
> > to use this logical slot and the primary ends up accumulating WALs.
> >
>
> Can we have a parameter like immediately_reserve in
> create_logical_slot API, similar to what we have for physical slots?
> We need to work out the details, but that should address the kind of
> use case you are worried about, unless I am missing something.

Interesting idea. One concern in my mind is that in the use case I
mentioned above, users would need to carefully manage the extra
logical slot to keep the logical decoding active. The logical decoding
is deactivated on the standby as soon as users drop all logical slots
on the primary.

Also, with this idea of automatically increasing WAL level, do we want
to keep the 'logical' WAL level? If so, it requires an extra step of
creating a non-reserved logical slot on the primary in order for the
standby to activate the logical decoding. On the other hand, we can
also keep the 'logical' WAL level for the compatibility and for making
the logical decoding enabled without the coordination of WAL level
transition. But wal_level GUC parameter would no longer tell the
actual WAL level to users when 'replica' + logical slots. Is it
sufficient to provide a read-only GUC parameter, say
effective_wal_level showing the actual WAL level being used?

Regards,

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