Re: VM corruption on standby
Andrey Borodin <x4mmm@yandex-team.ru>
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Yura Sokolov <y.sokolov@postgrespro.ru>,
Thomas Munro <thomas.munro@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T18:34:21Z
Lists: pgsql-hackers
> On 19 Aug 2025, at 23:23, Kirill Reshke <reshkekirill@gmail.com> wrote: > >> We'd probably be best off to get back to the actual bug the >> thread started with, namely whether we aren't doing the wrong >> thing with VM-update order of operations. >> >> regards, tom lane > > My understanding is that there is no bug in the VM. At least not in > [0] test, because it uses an injection point in the CRIT section, > making the server exit too early. > So, behaviour with inj point and without are very different. > The corruption we are looking for has to reproducer (see [1]). I believe there is a bug with PageIsAllVisible(page) && visibilitymap_clear(). But I cannot prove it with an injection point test. Because injections points rely on CondVar, that per se creates corruption in critical section. So I'm reading this discussion and wonder if CondVar will be fixed in some clever way or I'd better invent new injection point wait mechanism. Best regards, Andrey Borodin.
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