| From: | Christophe Pettus <xof(at)thebuild(dot)com> |
|---|---|
| To: | "pgsql-generallists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
| Subject: | Advancing the archiver position safely |
| Date: | 2020-08-07 00:43:29 |
| Message-ID: | 520661CC-7D55-4E6C-9474-35FA7974F8D0@thebuild.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
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(at)thebuild(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jerry Sievers | 2020-08-07 01:45:55 | Re: Advancing the archiver position safely |
| Previous Message | Bruce Momjian | 2020-08-06 22:18:59 | Re: Can PAF be used to provide zero downtime while primary and backup servers are being patched? |