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. -- With Regards, Amit Kapila.
