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.pg@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.
Thanks!
> The attached v12 patches
> majorly have the following changes:
>
> 2. last_inactive_at and inactive_timeout are now tracked in on-disk
> replication slot data structure.
Should last_inactive_at be tracked on disk? Say the engine is down for a period
of time > inactive_timeout then the slot will be invalidated after the engine
re-start (if no activity before we invalidate the slot). Should the time the
engine is down be counted as "inactive" time? I've the feeling it should not, and
that we should only take into account inactive time while the engine is up.
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com