Re: VM corruption on standby
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kirill Reshke <reshkekirill@gmail.com>
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-18T16:52:27Z
Lists: pgsql-hackers
Kirill Reshke <reshkekirill@gmail.com> writes: > On Sun, 17 Aug 2025 at 19:33, Tom Lane <tgl@sss.pgh.pa.us> 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 under the > impression that CRIT sections are something that backend (or other) > postgres processes try to pass quickly. So, what this patch is doing, > is that it defers the process reaction to postmaster death until the > end of the CRIT section. Well, if you're inside WaitEventSetWaitBlock, you have little control over how long you're going to sit. There is a separate discussion to be had over whether we should prohibit calling that function inside a critical section. But I'm of the opinion that proc_exit is the wrong thing to use after seeing postmaster death, critical section or no. We should assume that system integrity is already compromised, and get out as fast as we can with as few side-effects as possible. It'll be up to the next generation of postmaster to try to clean up. regards, tom lane
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