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-18T08:15:18Z
Lists: pgsql-hackers
Hi! Thank you for putting attention to this. On Sun, 17 Aug 2025 at 19:33, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Kirill Reshke <reshkekirill@gmail.com> writes: > > [ v1-0001-Do-not-exit-on-postmaster-death-ever-inside-CRIT-.patch ] > > 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. So, typical scenario here (as I understand) is this: (1) Process doing its goods, enters CRIT section. (2) Postmaster dies. (3a) Signal of postmaster death (SIGPWR on my VM) delivered to process (3b) Process exists CRIT sections, and then does CFI logic, observes postmaster death and quits. This is why I did my patch the way I did it. I mean, is it always possible for race conditions to occur, which will result in late signal delivery, so why bother and all? > I think the actual bug here is the use of proc_exit(1) after > observing postmaster death. Agreed. > So I think the correct fix here is s/proc_exit(1)/_exit(2)/ in the > places that are responding to postmaster death. There might be > more than just WaitEventSetWaitBlock; I didn't look. Well, I see that patching this way will be a much safer way to fix the issue. I can see that doing more conservative changes can be more beneficial (more future-proof and less bug-prone). I will take a detailed look and try to send a patch soon. -- 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