Re: VM corruption on standby
Kirill Reshke <reshkekirill@gmail.com>
From: Kirill Reshke <reshkekirill@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>
Date: 2025-08-18T10:32:19Z
Lists: pgsql-hackers
Attachments
- v2-0001-Do-not-exit-on-postmaster-death-even-inside-CRIT-.patch (application/octet-stream) patch v2-0001
On Mon, 18 Aug 2025 at 13:15, I wrote: > > I do not like this patch one bit: it will replace one set of problems > > with another set, namely systems that fail to shut down. > > I did not observe this during my by-hand testing. I am sorry: I was wrong. This is exactly what happens in this test (modified 001_multixact.pl). To be precise, after the INSERT process exits, CHECKPOINT process waits indefinitely in LWLockAcquire. It looks like the reason why proc_exit(1) releases all holded lwlocks is because we use it to notify all lwlock contenders through shared memory about state change, which will not be notified otherwise, since we do not check for signals inside LWLockAcquire. Looks like we need to do something like ConditionVariableBroadcast(), but without lwlock release, to notify all lwlock contenders and then exit(2). === As for the fix, I am now trying to make attached work. The idea to "escalate" proc_exit to immediately exit via syscall comes to my mind from how elog(ERROR) behaves in CRIT sections (every elog(ERROR) efficiently becomes elog(PANIC)). -- 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