From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Subject: | Re: First-draft release notes for back-branch releases |
Date: | 2018-11-07 02:06:13 |
Message-ID: | 87sh0dzmh7.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>>>>> "Michael" == Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> So while there _probably_ isn't any data corruption, the standby can
>> get into a state that isn't restartable unless you know to block
>> client connections to it until it has caught up. Rebuilding the
>> standby from the master will work but that may be a significant
>> practical problem if the data is large.
Michael> The problem would show up if you enforce a crash recovery when
Michael> restarting the standby, not after when letting it shut down
Michael> cleanly.
No. The problem shows up on clean shutdowns of the standby too.
For example, I just shut down using pg_ctl stop -mfast the standby side
of the 9.5.14 cluster I've been testing with. Observe:
Database cluster state: shut down in recovery
pg_control last modified: Wed Nov 7 01:47:33 2018
Latest checkpoint location: 0/201FCF70
Prior checkpoint location: 0/C541B40
Latest checkpoint's REDO location: 0/138D2038
...
Minimum recovery ending location: 0/201FCFE0
So the minimum recovery location is recorded as 0x201FCFE0, but there
are data pages on disk with LSNs as recent as 0x25BAFE80. That's a whole
lot of daylight that could contain a btree delete.
--
Andrew (irc:RhodiumToad)
From | Date | Subject | |
---|---|---|---|
Next Message | Noah Misch | 2018-11-07 02:28:45 | Re: First-draft release notes for back-branch releases |
Previous Message | Michael Paquier | 2018-11-07 01:56:00 | Re: Doc patch on psql output formats |