Horton
Menu

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-07T15:17:17Z
Lists: pgsql-hackers 
Hi,

> 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 [...]
>
> A draft patch is attached. It makes the test pass and doesn't seem to
> break any other tests.
>
> Thoughts?

In order not to forget - assuming I'm not wrong about the cause of the
issue, we might want to recheck the order of visibilitymap_* and XLog*
calls in the following functions too:

- heap_multi_insert
- heap_delete
- heap_update
- heap_lock_tuple
- heap_lock_updated_tuple_rec

By a quick look all named functions modify the VM before making a
corresponding WAL record. This can cause a similar issue:

1. VM modified
2. evicted asynchronously before logging
3. kill 9
4. different state of VM on primary and standby

Commits

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

  1. Revert "Get rid of WALBufMappingLock"

  2. Get rid of WALBufMappingLock

  3. Split WaitEventSet functions to separate source file

  4. Add WL_EXIT_ON_PM_DEATH pseudo-event.