From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | James Coleman <jtc331(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_rewind: warn when checkpoint hasn't happened after promotion |
Date: | 2022-07-05 18:51:35 |
Message-ID: | CA+TgmoY3sXgOUiY7WF3J-9k+CUUXSG=JEcP2Qe9Nj_o7oeY5vQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 5, 2022 at 2:47 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-07-05 18:52:05 | Re: PSA: Autoconf has risen from the dead |
Previous Message | Peter Geoghegan | 2022-07-05 18:51:31 | Re: First draft of the PG 15 release notes |