Re: VM corruption on standby
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kirill Reshke <reshkekirill@gmail.com>, Andrey Borodin <x4mmm@yandex-team.ru>,
PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T14:57:43Z
Lists: pgsql-hackers
Hi, On 2025-08-20 02:54:09 +1200, Thomas Munro wrote: > > On linux - the primary OS with OOM killer troubles - I'm pretty sure'll lwlock > > waiters would get killed due to the postmaster death signal we've configured > > (c.f. PostmasterDeathSignalInit()). > > No, that has a handler that just sets a global variable. That was > done because recovery used to try to read() from the postmaster pipe > after replaying every record. Also we currently have some places that > don't want to be summarily killed (off the top of my head, syncrep > wants to send a special error message, and the logger wants to survive > longer than everyone else to catch as much output as possible, things > I've been thinking about in the context of threads). That makes no sense. We should just _exit(). If postmaster has been killed, trying to stay up longer just makes everything more fragile. Waiting for the logger is *exactly* what we should *not* do - what if the logger also crashed? There's no postmaster around to start it. Greetings, Andres Freund
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