Re: PITR promote bug: Checkpointer writes to older timeline
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: masao.fujii@oss.nttdata.com, soumyadeep2007@gmail.com, hlinnaka@iki.fi, pgsql-hackers@postgresql.org, jyih@vmware.com, kyeap@vmware.com
Date: 2021-03-22T00:07:19Z
Lists: pgsql-hackers
On Thu, Mar 18, 2021 at 12:56:12PM +0900, Michael Paquier wrote: > I was looking at uses of ThisTimeLineID in the wild, and could not > find it getting checked or used actually in backend-side code that > involved the WAL reader facility. Even if it brings confidence, it > does not mean that it is not used somewhere :/ I have been working on that over the last couple of days, and applied a fix down to 10. One thing that I did not like in the test was the use of compare() to check if the contents of the WAL segment before and after the timeline jump remained the same as this would have been unstable with any concurrent activity. Instead, I have added a phase at the end of the test with an extra checkpoint and recovery triggered once, which is enough to reproduce the PANIC reported at the top of the thread. I'll look into clarifying the use of ThisTimeLineID within the those WAL reader callbacks, because this is really bug-prone in the long term... This requires some coordination with the recent work aimed at adding some logical decoding support in standbys, though. -- Michael
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix timeline assignment in checkpoints with 2PC transactions
- 1ec7162a8d34 10.17 landed
- f1d550f188e2 11.12 landed
- 4b1dd9b1ea75 12.7 landed
- 6e5ce888ad1e 13.3 landed
- 595b9cba2ab0 14.0 landed