| From: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com> |
| Subject: | Re: VM corruption on standby |
| Date: | 2025-08-19 06:26:13 |
| Message-ID: | CALdSSPjTH7f48h6ZGPbi6zuVoByEkM9M-M-94s5nPjiofDA03A@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 19 Aug 2025 at 10:32, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
>
> I don't know if there are other ways that LWLockReleaseAll() can lead
> to persistent corruption that won't be corrected by crash recovery,
> but this one is probably new since the following commit, explaining
> the failure to reproduce on v17:
>
> commit bc22dc0e0ddc2dcb6043a732415019cc6b6bf683
> Author: Alexander Korotkov <akorotkov(at)postgresql(dot)org>
> Date: Wed Apr 2 12:44:24 2025 +0300
>
> Get rid of WALBufMappingLock
>
> Any idea involving deferring the handling of PM death from here
> doesn't seem right: you'd keep waiting for the CV, but the backend
> that would wake you might have exited.
I revert this commit (these were conflicts but i resolved them) and
added assert for crit sections in WaitEventSetWait.
make check passes (without v2-0001 it fails)
--
Best regards,
Kirill Reshke
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Revert-Get-rid-of-WALBufMappingLock.patch | application/octet-stream | 15.8 KB |
| v2-0002-Add-assertion-for-WaitEventSetWait-in-crit-sectio.patch | application/octet-stream | 773 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrei Lepikhov | 2025-08-19 06:29:43 | Re: Plan caching and serialization for reuse across executions |
| Previous Message | Michael Paquier | 2025-08-19 06:24:39 | Remove traces of long in dynahash.c |