| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Kirill Reshke <reshkekirill(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
| Subject: | Re: VM corruption on standby |
| Date: | 2025-08-18 06:43:05 |
| Message-ID: | 3A177D8E-99D3-48E0-AD31-B2B12063CABF@yandex-team.ru |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> On 17 Aug 2025, at 17:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> So I think the correct fix here is s/proc_exit(1)/_exit(2)/ in the
> places that are responding to postmaster death.
+1. But should we _exit(2) only in critical section or always in case of postmaster death?
Another question that was bothering Kirill is do we want a test that naturally reproduces WaitEventSetWaitBlock() under critical section so that we can observe a corruption? Or is it kind of obvious from code that such things might happen?
Existing test is adding WaitEventSetWaitBlock() via injection point to a place where it was not present before. Though with existing test at hand we can check that fix is curing WaitEventSetWaitBlock() against critical section.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-08-18 06:49:41 | Re: [Proposal] Expose internal MultiXact member count function for efficient monitoring |
| Previous Message | Laurenz Albe | 2025-08-18 06:40:02 | Re: analyze-in-stages post upgrade questions |