Re: [HACKERS] Broken hint bits (freeze) - Mailing list pgsql-hackers

From Vladimir Borodin
Subject Re: [HACKERS] Broken hint bits (freeze)
Date
Msg-id 2E86EB5F-50ED-4DE2-B14E-98EF8F62B2F2@simply.name
Whole thread Raw
In response to Re: [HACKERS] Broken hint bits (freeze)  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [HACKERS] Broken hint bits (freeze)  (Andres Freund <andres@anarazel.de>)
Re: [HACKERS] Broken hint bits (freeze)  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers

26 мая 2017 г., в 21:39, Amit Kapila <amit.kapila16@gmail.com> написал(а):

And LSN on replica is greater that LSN on master (838D/C4A0D280 > 8092/6A26DD08)
How can this be possible?


Yeah, I think this is quite suspicious.  This seems to indicate that
not all WAL records are replicated before the switchover.  What is the
value of "synchronous_commit" you are using?

synchronous_commit = on.

 I think you somehow need
to ensure before switchover that all the WAL is replicated to ensure
this is not a setup problem.

Well, actually clean shutdown of master with exit code 0 from `pg_ctl stop -m fast` guarantees that all WAL has been replicated to standby. But just in case we also check that "Latest checkpoint's REDO location" from control file on old master after shutdown is less than pg_last_xlog_replay_location() on standby to be promoted.

And if something would go wrong in above logic, postgres will not let you attach old master as a standby of new master. So it is highly probable not a setup problem.

--
May the force be with you…

pgsql-hackers by date:

Previous
From: Erik Rijkers
Date:
Subject: Re: [HACKERS] logical replication - still unstable after all thesemonths
Next
From: Andres Freund
Date:
Subject: Re: [HACKERS] Broken hint bits (freeze)