On Sun, Jul 20, 2025 at 11:53 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Jul 21, 2025 at 11:24 AM shveta malik <shveta.ma...@gmail.com> wrote: > > > > On Mon, Jul 21, 2025 at 10:48 AM shveta malik <shveta.ma...@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
