Re: BUG #18575: Sometimes pg_rewind mistakenly assumes that nothing needs to be done.
Georgy Shelkovy <g.shelkovy@arenadata.io>
From: Georgy Shelkovy <g.shelkovy@arenadata.io>
To: Heikki Linnakangas <hlinnaka@iki.fi>, "pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Date: 2024-08-08T09:38:21Z
Lists: pgsql-bugs
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix pg_rewind debug output to print the source timeline history
- e8240dbd86f7 16.5 landed
- b5a5027c9796 15.9 landed
- bb5592cacede 14.14 landed
- c943e2aae7c5 13.17 landed
- 8b86e289f7f0 12.21 landed
- a7bf3e668527 17.0 landed
- 49dc191bd1ae 18.0 landed
Attachments
On second run I got bug
08.08.2024, 14:30, "Heikki Linnakangas" <hlinnaka@iki.fi>:
On 08/08/2024 10:57, Georgy Shelkovy wrote:
Unfortunately, the playback is not very stable, but sometimes it shoots.
I added some commands to show last WAL rows
Thanks. I still haven't been able to reproduce it, but here's a theory:
When determining whether the target needs rewinding, pg_rewind looks at
the target's last checkpoint record, or if it's a standby, its
minRecoveryPoint. It's possible that standby2's minRecoveryPoint is
indeed before the point of divergence. That means it has replayed the
340 insert records, but all the changes are still only sitting in the
shared buffer cache. When you shut it down, those 340 inserts are gone
on standby2. When you restart it, they will be applied again from the WAL.
In that case, pg_rewind's conclusion that no rewind is needed is
correct. standby2 is strictly behind standby1, and could catch up
directly to it. However, when you restart standby2, it will first replay
the WAL it had streamed from master.
Can you show the full output of pg_controldata on all the servers,
please? In your latest snippet, you showed just the checkpoint
locations, but if just remove the "grep checkpoint | grep location"
filters, it would print the whole thing. I'm particularly interested in
the minRecoveryPoint on standby2, in the cases when it works and when it
doesn't.
I'm not sure what the right behavior would be if that's the issue.
Perhaps pg_rewind should truncate the WAL in standby2/pg_wal/ in that
case, so that when you start it up again, it would not replay the local
WAL but would connect to standby2 directly. Also, perhaps a fast
shutdown of a standby server should update minRecoveryPoint before exiting.
--
Heikki Linnakangas
Neon (https://neon.tech)