On Thu, Mar 21, 2024 at 11:37 AM Bertrand Drouvot <bertranddrouvot...@gmail.com> wrote: > > On Thu, Mar 21, 2024 at 10:53:54AM +0530, Bharath Rupireddy wrote: > > On Thu, Mar 21, 2024 at 9:07 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > But the issue is that it would make it inconsistent with the new > > > > > inactivetimeout > > > > > in the subscription that is added in "v12-0005". > > > > > > > > Can you please elaborate what the inconsistency it causes with > > > > inactivetimeout? > > > > > > > I think the inconsistency can arise from the fact that on publisher > > > one can change the inactive_timeout for the slot corresponding to a > > > subscription but the subscriber won't know, so it will still show the > > > old value. > > Yeah, that was what I had in mind. > > > > If we want we can document this as a limitation and let > > > users be aware of it. However, I feel at this stage, let's not even > > > expose this from the subscription or maybe we can discuss it once/if > > > we are done with other patches. > > I agree, it's important to expose it for things like "failover" but I think we > can get rid of it for the timeout one. > > >> Anyway, if one wants to use this > > > feature with a subscription, she can create a slot first on the > > > publisher with inactive_timeout value and then associate such a slot > > > with a required subscription. > > Right. > > > > > If we are not exposing it via subscription (meaning, we don't consider > > v13-0004 and v13-0005 patches), I feel we can have a new SQL API > > pg_alter_replication_slot(int inactive_timeout) for now just altering > > the inactive_timeout of a given slot. > > Agree, that seems more "natural" that going through a replication connection. > > > With this approach, one can do either of the following: > > 1) Create a slot with SQL API with inactive_timeout set, and use it > > for subscriptions or for streaming standbys. > > Yes. > > > 2) Create a slot with SQL API without inactive_timeout set, use it for > > subscriptions or for streaming standbys, and set inactive_timeout > > later via pg_alter_replication_slot() depending on how the slot is > > consumed > > Yes. > > > 3) Create a subscription with create_slot=true, and set > > inactive_timeout via pg_alter_replication_slot() depending on how the > > slot is consumed. > > Yes. > > We could also do the above 3 and altering the timeout with a replication > connection but the SQL API seems more natural to me. >
If we want to go with this then I think we should at least ensure that if one specified timeout via CREATE_REPLICATION_SLOT or ALTER_REPLICATION_SLOT that should be honored. -- With Regards, Amit Kapila.
