From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | James Coleman <jtc331(at)gmail(dot)com> |
Cc: | 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:39:11 |
Message-ID: | CA+TgmobSbJ9Z=MxC+i12SUBDnqV9vUmW5zBzAwQyKT=XpOaTwQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jun 4, 2022 at 8:59 AM James Coleman <jtc331(at)gmail(dot)com> wrote:
> A quick background refresher: after promoting a standby rewinding the
> former primary requires that a checkpoint have been completed on the
> new primary after promotion. This is correctly documented. However
> pg_rewind incorrectly reports to the user that a rewind isn't
> necessary because the source and target are on the same timeline.
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.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2022-07-05 18:40:21 | Re: pg15b2: large objects lost on upgrade |
Previous Message | Andres Freund | 2022-07-05 18:36:02 | Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size |