Re: pgsql: Track last_inactive_time in pg_replication_slots.

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pgsql: Track last_inactive_time in pg_replication_slots.
Дата
Msg-id CA+TgmoaCA-aaBiszkMKOTn6C3BKkY4hNAdNOLUhfMXdQxyrh9g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pgsql: Track last_inactive_time in pg_replication_slots.  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: pgsql: Track last_inactive_time in pg_replication_slots.  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-hackers
On Mon, Mar 25, 2024 at 10:02 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> We considered the other two names as last_inactive_at and
> last_active_time. For the first (last_inactive_at), there was an
> argument that most other fields that display time ends with _time. For
> the second (last_active_time), there was an argument that it could be
> misleading as one could think that it should be updated each time WAL
> record decoding is happening [1]. The other possibility is to name it
> last_used_time but I think it won't be much different from
> last_active_time.

I don't understand the bit about updating it each time WAL record
decoding is happening. If it's the last active time, and the slot is
currently active, then the answer is either "right now" or "currently
undefined." I'd expect to see NULL in the system view in such a case.
And if that's so, then there's nothing to update each time a record is
decoded, because it's just still going to show NULL.

Why does this field get set to the current time when the slot is
restored from disk?

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Refactoring of pg_resetwal/t/001_basic.pl
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Recording whether Heap2/PRUNE records are from VACUUM or from opportunistic pruning (Was: Show various offset arrays for heap WAL records)