Re: VM corruption on standby

Aleksander Alekseev <aleksander@tigerdata.com>

View thread

From: Aleksander Alekseev <aleksander@tigerdata.com>

To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Melanie Plageman <melanieplageman@gmail.com>

Date: 2025-08-07T14:09:39Z

Lists: pgsql-hackers

Attachments

v2-0001-Corrupt-VM-on-standby.patch (text/x-patch) patch v2-0001
v2-0002-Bugfix-TODO-FIXME-write-a-better-message.patch (text/x-patch) patch v2-0002

Hi,

> This is a tricky bug. Do you also have a proposal of a particular fix?

If my understanding is correct, we should make a WAL record with the
XLH_LOCK_ALL_FROZEN_CLEARED flag *before* we modify the VM but within
the same critical section (in order to avoid race conditions within
the same backend).

A draft patch is attached. It makes the test pass and doesn't seem to
break any other tests.

Thoughts?

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Revert "Get rid of WALBufMappingLock"
- 2ce6abdf5085 18.0 landed
- c13070a27b63 19 (unreleased) landed
Get rid of WALBufMappingLock
- bc22dc0e0ddc 18.0 cited
Split WaitEventSet functions to separate source file
- 393e0d231405 18.0 cited
Add WL_EXIT_ON_PM_DEATH pseudo-event.
- cfdf4dc4fc96 12.0 cited