Re: VM corruption on standby
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Kirill Reshke <reshkekirill@gmail.com>, Yura Sokolov <y.sokolov@postgrespro.ru>, Thomas Munro <thomas.munro@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Melanie Plageman <melanieplageman@gmail.com>
Date: 2025-08-19T22:33:12Z
Lists: pgsql-hackers
On Tue, Aug 19, 2025 at 03:55:41PM -0400, Tom Lane wrote: > Yeah, I was coming to similar conclusions in the reply I just sent: > we don't really want a policy that we can't put injection-point-based > delays inside critical sections. So that infrastructure is leaving > something to be desired. Yes, it doesn't make sense to restrict the use of injection point waits within critical sections. A simple switch that we could do is to rely on a clock-based check in the wait() routine, removing the condition variable part. It costs in responsiveness because the wakeup() routine would not be able to ping the wait() part to recheck the shmem counter immediately. But we could reduce the delay with a variable recheck timing, say double the time to recheck the counter after each loop, capped at a maximum of a couple of hundred ms so as it's still good enough on fast machines, and does not stress too much slow machines. That costs a bit more in terms of clock calls and delay checks, but it would be low-level enough that the internal interrupts would not matter if we rely on syscalls, I guess? And we don't care about efficiency in this case. -- Michael
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