On Mon, Jul 21, 2025 at 12:23 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > I am slightly hesitant to introduce multiple ways to enable logical > decoding/replication unless that is the only path as giving multiple > options to achieve the same thing can confuse users as to which one is > preferable and pros/cons of each.
Okay I understand your concern and it is a valid one. > > > > 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. > I feel introducing a GUC is the simplest approach, as it provides users with some control over the behavior when handling the last logical slot. With this safeguard in place, we can be more confident about eventually removing wal_level = logical, either now or in the future. That said, if we decide it's acceptable to proceed without this additional ERROR/WARNING mechanism, I'm fine with that as well. But it does leave users with a small risk of unintentionally disabling logical decoding, even with proper documentation. Let's see what others think here. thanks Shveta
