On Mon, Mar 25, 2024 at 9:55 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Mon, Mar 25, 2024 at 12:12 PM Bertrand Drouvot > <bertranddrouvot...@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). >
We have a consensus on inactive_since, so I'll make that change. I would also like to solicit your opinion on the other slot-level parameter we are planning to introduce. This new slot-level parameter will be named as inactive_timeout. This will indicate that once the slot is inactive for the inactive_timeout period, we will invalidate the slot. We are also discussing to have this parameter (inactive_timeout) as GUC [1]. We can have this new parameter both at the slot level and as well as a GUC, or just one of those. [1] - https://www.postgresql.org/message-id/20240325195443.GA2923888%40nathanxps13 -- With Regards, Amit Kapila.
