Re: pg_rewind: warn when checkpoint hasn't happened after promotion
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: James Coleman <jtc331@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-07-05T18:51:35Z
Lists: pgsql-hackers
On Tue, Jul 5, 2022 at 2:47 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > Is there anything intrinsic to the mechanism of operation of pg_rewind > > that requires a timeline change, or could we just rewind within the > > same timeline to an earlier LSN? In other words, maybe we could just > > remove this limitation of pg_rewind, and then perhaps it wouldn't be > > necessary to determine what the new timeline is. > > That seems like a fairly bad idea. For example, if you've already > archived some WAL segments past the rewind target, there will shortly > be two versions of truth about what that part of the WAL space contains, > and your archiver will either spit up or do probably-the-wrong-thing. Well, only if you void the warranty. If you rewind the ex-primary to the LSN where the new primary is replaying and tell it to start replaying from there and follow the new primary's subsequent switch onto a new timeline, there's no split-brain problem. -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
pg_rewind: Remove notice in docs about running CHECKPOINT after promote.
- 0a0500207a94 16.0 landed
-
pg_rewind: Fix determining TLI when server was just promoted.
- 009eeee74682 16.0 cited