Re: pg_rewind: warn when checkpoint hasn't happened after promotion

On Tue, Jun 07, 2022 at 12:39:38PM +0900, Kyotaro Horiguchi wrote:
> At Mon, 6 Jun 2022 08:32:01 -0400, James Coleman <jtc331(at)gmail(dot)com> wrote in
>> To confirm I'm following you correctly, you're envisioning a situation like:
>>
>> - Primary A
>> - Replica B replicating from primary
>> - Replica C replicating from replica B
>>
>> then on failover from A to B you end up with:
>>
>> - Primary B
>> - Replica C replication from primary
>> - [needs rewind] A
>>
>> and you try to rewind A from C as the source?
>
> Yes. I think it is a legit use case. That being said, like other
> points, it might be acceptable.

This configuration is a case supported by pg_rewind, meaning that your
patch to check after minRecoveryPointTLI would be confusing when using
a standby as a source because the checkpoint needs to apply on its
primary to allow the TLI of the standby to go up. If you want to
provide to the user more context, a more meaningful way may be to rely
on an extra check for ControlFileData.state, I guess, as a promoted
cluster is marked as DB_IN_PRODUCTION before recoveryMinPoint is
cleared by the first post-promotion checkpoint, with
DB_IN_ARCHIVE_RECOVERY for a cascading standby.
--
Michael