I've encountered a rather unusual situation (PostgreSQL 9.6). On a particular server, for reasons I've not fully diagnosed, the archiver thinks that the current WAL segment to be archived is 0000000200003B6800000062. This is unfortunate, because the oldest WAL segment that actually exists on disk is 0000000200003F1100000004, so the archive script is failing repeatedly because of the missing segment. The system is not actually missing important (for recovery) WAL segments, at least: Latest checkpoint's REDO WAL file: 000000020000417600000029 I'd like to "catch up" the archiver such that it is operating on files that actually exist; besides setting archive_command to '/bin/true' and letting it chew through the old ones, is there a way of safely advancing the position of the archiver? -- -- Christophe Pettus xof@xxxxxxxxxxxx
