Horton

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>

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

			regards, tom lane

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.