Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)
Дата
Msg-id 40de25aa-2e20-08ad-e014-edb731594a74@iki.fi
обсуждение исходный текст
Ответ на Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: last_archived_wal is not necessary the latest WAL file (was Re: pgsql: Add test case for an archive recovery corner case.)  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On 15/02/2022 23:28, Tom Lane wrote:
> Heikki Linnakangas <hlinnaka@iki.fi> writes:
>> That was interesting: the order that WAL segments are archived when a
>> standby is promoted is not fully deterministic.
> 
> Oh, of course.
> 
>> I find it a bit surprising that pg_stat_archiver.last_archived_wal is
>> not necessarily the highest-numbered segment that was archived. I
>> propose that we mention that in the docs, as in the attached patch.
> 
> +1, but I think the description of that field in the pg-stat-archiver-view
> table is also pretty misleading.  Maybe like
> 
> -      Name of the last WAL file successfully archived
> +      Name of the WAL file most recently successfully archived
> 
> and similarly s/last/most recent/ for the other fields claiming
> to be "last" something.

Makes sense, committed it that way.

- Heikki



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Column Filtering in Logical Replication
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Race conditions in 019_replslot_limit.pl