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

On Sun, Jul 20, 2025 at 11:53 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Jul 21, 2025 at 11:24 AM shveta malik <shveta.malik@gmail.com> wrote:
> >
> > On Mon, Jul 21, 2025 at 10:48 AM shveta malik <shveta.malik@gmail.com> wrote:
> > >
> > > I'm continuing to think it through and will share any further thoughts
> > > if something comes to mind.
> > >
> >
> > How about a parameter named 'on_last_logical_slot' with possible
> > values: 'error', 'warn', 'drop', 'retain'?
> > Alternatively, we could use 'last_logical_slot_drop_policy' with
> > values: 'error', 'warn', 'allow'.
> >
> > These parameters could be supported by both DROP SUBSCRIPTION and
> > pg_drop_replication_slot(), or alternatively implemented as a GUC on
> > the primary server. The default value should be either 'warn' or,
> > preferably, 'error' for safer behavior.
> >
> > It seems more logical to me for this to be a GUC on the primary since
> > it falls within the primary’s scope.
> >
>
> This is worth considering. OTOH, it is possible that we are over
> worried about users accidentally dropping the slot required for
> continuing the logical decoding on the physical standby. In the
> publisher-subscriber model, it seems quite intuitive that as soon as
> the first subscription is created, we enable logical decoding on the
> primary and when the last subscription is dropped, the logical
> decoding on the publisher gets disabled. The case we are worrying
> about is, for users, that enable logical decoding/replication on
> physical standby based on the presence of a logical slot on the
> primary. I think if we have documented clearly it is the
> responsibility of users that they need to either (a) keep wal_level as
> logical on primary, or (b) preserve a slot on the primary, it should
> be sufficient. There could be multiple ways to preserve the slot, one
> is users always create a special slot on the primary for this purpose
> or we can provide a slot_option which users can specify/alter so that
> they get ERROR/WARNING on the last such slot being dropped. I feel we
> should choose the simplest option and rely on users to use the feature
> appropriately. We can always enhance the feature in future versions
> based on feedback from the field.

Yes, I agree. The main patch focuses on the part where we
automatically change the effective WAL level upon the logical slot
creation and deletion (and potentially remove 'logical' from
wal_level), and other things are implemented as additional features in
a separate patch. In the case where users are using logical decoding
only on the standbys, we might want to have a concept like empty
logical slots as we have discussed because users would not want to let
a logical slot on the primary preserve anything. But it's a separate
discussion whether we provide a way to protect such a slot from being
dropped or used mistakenly.

Regards,

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