Horton

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 <hlinnaka@iki.fi>

View thread View on postgr.es
From: Heikki Linnakangas <hlinnaka@iki.fi>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-02-15T23:42:27Z
Lists: 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

Commits

  1. Fix race condition in t/028_pitr_timelines.pl.

  2. Fix race condition in 028_pitr_timelines.pl test, add note to docs.

  3. Add more logging to new 028_pitr_timelines.pl test.

  4. Add test case for an archive recovery corner case.