On Thu, Mar 21, 2024 at 11:37 AM Bertrand Drouvot
<bertranddrouvot.pg@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.kapila16@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.