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: Thomas Munro <thomas.munro@gmail.com>,
Andrey Borodin <x4mmm@yandex-team.ru>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T06:17:03Z
Lists: pgsql-hackers
On Tue, 19 Aug 2025 at 11:13, Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Thomas Munro <thomas.munro@gmail.com> writes: > > On Tue, Aug 19, 2025 at 4:52 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> 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. > > > Then wouldn't backends blocked in LWLockAcquire(x) hang forever, after > > someone who holds x calls _exit()? > > If someone who holds x is killed by (say) the OOM killer, how do > we get out of that? +1, if we kill-9 PM and then immediately kill-9 lwlock holder, there is no way for system to shutdown (both HEAD and back branches). So we can ignore this case. -- 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