Re: pgsql: Track last_inactive_time in pg_replication_slots. - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: pgsql: Track last_inactive_time in pg_replication_slots.
Date
Msg-id ZgGrCBQoktdLi1Ir@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: pgsql: Track last_inactive_time in pg_replication_slots.  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: pgsql: Track last_inactive_time in pg_replication_slots.
List pgsql-hackers
Hi,

On Mon, Mar 25, 2024 at 12:25:37PM -0400, Robert Haas wrote:
> On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> > Would "released_time" sounds better? (at the end this is exactly what it does
> > represent unless for the case where it is restored from disk for which the meaning
> > would still makes sense to me though). It seems to me that released_time does not
> > lead to any expectation then removing any confusion.
> 
> Yeah, that's not bad. I mean, I don't agree that released_time doesn't
> lead to any expectation,
> but what it leads me to expect is that you're
> going to tell me the time at which the slot was released. So if it's
> currently active, then I see NULL, because it's not released; but if
> it's inactive, then I see the time at which it became so.
> 
> In the same vein, I think deactivated_at or inactive_since might be
> good names to consider. I think they get at the same thing as
> released_time, but they avoid introducing a completely new word
> (release, as opposed to active/inactive).
> 

Yeah, I'd vote for inactive_since then.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions
Next
From: Robert Haas
Date:
Subject: Re: Possibility to disable `ALTER SYSTEM`