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

From Robert Haas
Subject Re: pgsql: Track last_inactive_time in pg_replication_slots.
Date
Msg-id CA+TgmoZj8zDJUdEXr4BP5MQvpUkj82M7APeOUTRUQUS_cVdGHg@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Track last_inactive_time in pg_replication_slots.  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: pgsql: Track last_inactive_time in pg_replication_slots.
Re: pgsql: Track last_inactive_time in pg_replication_slots.
List pgsql-hackers
On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> Now that I read your arguments I think that last_<active|inactive>_time could be
> both missleading because at the end they rely on users "expectation".

Well, the user is always going to expect *something* -- that's just
how language works.

> 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).

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bertrand Drouvot
Date:
Subject: Re: pgsql: Track last_inactive_time in pg_replication_slots.
Next
From: Dmitry Dolgov
Date:
Subject: Re: pg_stat_statements and "IN" conditions