Re: Infinite loop in XLogPageRead() on standby
Kyotaro Horiguchi <horikyota.ntt@gmail.com>
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: cyberdemn@gmail.com
Cc: michael@paquier.xyz, pgsql-hackers@postgresql.org,
thomas.munro@gmail.com
Date: 2024-03-13T02:56:21Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix header check for continuation records where standbys could be stuck
- 0f0431e919f4 13.19 landed
- a2d4f806c4b9 14.16 landed
- 26554faccc97 15.11 landed
- 2c2e1d4f42c0 16.7 landed
- e6767c0ed16f 17.3 landed
- 6cf1647d87e7 18.0 landed
-
Move routines to manipulate WAL into PostgreSQL::Test::Cluster
- c9e50ce2a044 13.19 landed
- 50406b15540c 14.16 landed
- e5d113057d5f 15.11 landed
- 9420f9bb61e6 16.7 landed
- 149ed87e22ce 17.3 landed
- 32a18cc0a73d 18.0 landed
-
Prevent archive recovery from scanning non-existent WAL files.
- 4bd0ad9e44be 13.0 cited
-
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited
At Mon, 11 Mar 2024 16:43:32 +0900 (JST), Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote in > Oh, I once saw the fix work, but seems not to be working after some > point. The new issue was a corruption of received WAL records on the > first standby, and it may be related to the setting. I identified the cause of the second issue. When I tried to replay the issue, the second standby accidentally received the old timeline's last page-spanning record till the end while the first standby was promoting (but it had not been read by recovery). In addition to that, on the second standby, there's a time window where the timeline increased but the first segment of the new timeline is not available yet. In this case, the second standby successfully reads the page-spanning record in the old timeline even after the second standby noticed that the timeline ID has been increased, thanks to the robustness of XLogFileReadAnyTLI(). I think the primary change to XLogPageRead that I suggested is correct (assuming the use of wal_segment_size instead of the constant). However, still XLogFileReadAnyTLI() has a chance to read the segment from the old timeline after the second standby notices a timeline switch, leading to the second issue. The second issue was fixed by preventing XLogFileReadAnyTLI from reading segments from older timelines than those suggested by the latest timeline history. (In other words, disabling the "AnyTLI" part). I recall that there was a discussion for commit 4bd0ad9e44, about the objective of allowing reading segments from older timelines than the timeline history suggests. In my faint memory, we concluded to postpone making the decision to remove the feature due to uncertainity about the objective. If there's no clear reason to continue using XLogFileReadAnyTLI(), I suggest we stop its use and instead adopt XLogFileReadOnTLHistory(), which reads segments that align precisely with the timeline history. Of course, regardless of the changes above, if recovery on the second standby had reached the end of the page-spanning record before redirection to the first standby, it would need pg_rewind to connect to the first standby. regards. -- Kyotaro Horiguchi NTT Open Source Software Center