Hi, On Wed, Mar 20, 2024 at 12:48:55AM +0530, Bharath Rupireddy wrote: > On Mon, Mar 18, 2024 at 3:02 PM Bertrand Drouvot > <bertranddrouvot...@gmail.com> wrote: > > > > > > Hm. Are you suggesting inactive_timeout to be a slot level parameter > > > > similar to 'failover' property added recently by > > > > c393308b69d229b664391ac583b9e07418d411b6 and > > > > 73292404370c9900a96e2bebdc7144f7010339cf? > > > > > > Yeah, I have something like that in mind. You can prepare the patch > > > but it would be good if others involved in this thread can also share > > > their opinion. > > > > I think it makes sense to put the inactive_timeout granularity at the slot > > level (as the activity could vary a lot say between one slot linked to a > > subcription and one linked to some plugins). As far max_slot_xid_age I've > > the > > feeling that a new GUC is good enough. > > Well, here I'm implementing the above idea. The attached v12 patches > majorly have the following changes: >
Regarding v12-0004: "Allow setting inactive_timeout in the replication command", shouldn't we also add an new SQL API say: pg_alter_replication_slot() that would allow to change the timeout property? That would allow users to alter this property without the need to make a replication connection. But the issue is that it would make it inconsistent with the new inactivetimeout in the subscription that is added in "v12-0005". But do we need to display subinactivetimeout in pg_subscription (and even allow it at subscription creation / alter) after all? (I've the feeling there is less such a need as compare to subfailover, subtwophasestate for example). Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com
