Horton
Menu

Re: VM corruption on standby

Yura Sokolov <y.sokolov@postgrespro.ru>

View thread
From: Yura Sokolov <y.sokolov@postgrespro.ru>
To: Kirill Reshke <reshkekirill@gmail.com>, Aleksander Alekseev <aleksander@tigerdata.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Andrey Borodin <x4mmm@yandex-team.ru>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T12:56:05Z
Lists: pgsql-hackers 
09.08.2025 22:54, Kirill Reshke пишет:
> On Thu, 7 Aug 2025 at 21:36, Aleksander Alekseev
> <aleksander@tigerdata.com> wrote:
> 
>> Perhaps there was a good
>> reason to update the VM *before* creating WAL records I'm unaware of.
> 
> Looks like 503c730 intentionally does it this way; however, I have not
> yet fully understood the reasoning behind it.

I repeat: there was no intention. Neither in commit message, nor in
discussion about.

There was intention to move visibilitymap_clear under heap page lock and
into critical section, but there were no any word about logging.

I believe, it was just an unfortunate oversight that the change is made
before logging.

-- 
regards
Yura Sokolov aka funny-falcon

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.