| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Vladimir Borodin <root(at)simply(dot)name> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dmitriy Sarafannikov <dsarafannikov(at)yandex(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Broken hint bits (freeze) |
| Date: | 2017-05-27 16:56:09 |
| Message-ID: | 20170527165609.gpywwbe2fub4llkq@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2017-05-27 19:48:24 +0300, Vladimir Borodin wrote:
> 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.
It does not. It makes it likely, but the connection to the standby
could be not up just then, you could run into walsender timeout, and a
bunch of other scenarios.
> 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.
The *redo* location? Or the checkpoint location itself? Because the
latter is what needs to be *equal* than the replay location not less
than. Normally there won't be other records inbetween, but that's not
guaranteed.
> 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.
There's no such guarantee. There's a bunch of checks that'll somewhat
likely trigger, but nothing more than that.
- Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vladimir Borodin | 2017-05-27 17:16:25 | Re: Broken hint bits (freeze) |
| Previous Message | Vladimir Borodin | 2017-05-27 16:48:24 | Re: Broken hint bits (freeze) |