Re: VM corruption on standby
Kirill Reshke <reshkekirill@gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T06:26:13Z
Lists: pgsql-hackers
Attachments
- v2-0001-Revert-Get-rid-of-WALBufMappingLock.patch (application/octet-stream) patch v2-0001
- v2-0002-Add-assertion-for-WaitEventSetWait-in-crit-sectio.patch (application/octet-stream) patch v2-0002
On Tue, 19 Aug 2025 at 10:32, Thomas Munro <thomas.munro@gmail.com> wrote: > > I don't know if there are other ways that LWLockReleaseAll() can lead > to persistent corruption that won't be corrected by crash recovery, > but this one is probably new since the following commit, explaining > the failure to reproduce on v17: > > commit bc22dc0e0ddc2dcb6043a732415019cc6b6bf683 > Author: Alexander Korotkov <akorotkov@postgresql.org> > Date: Wed Apr 2 12:44:24 2025 +0300 > > Get rid of WALBufMappingLock > > Any idea involving deferring the handling of PM death from here > doesn't seem right: you'd keep waiting for the CV, but the backend > that would wake you might have exited. I revert this commit (these were conflicts but i resolved them) and added assert for crit sections in WaitEventSetWait. make check passes (without v2-0001 it fails) -- Best regards, Kirill Reshke
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