On Tue, Jun 07, 2022 at 12:39:38PM +0900, Kyotaro Horiguchi wrote: > At Mon, 6 Jun 2022 08:32:01 -0400, James Coleman <jtc...@gmail.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
signature.asc
Description: PGP signature
