From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
Cc: | 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>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Subject: | Re: VM corruption on standby |
Date: | 2025-08-18 16:52:27 |
Message-ID: | 421825.1755535947@sss.pgh.pa.us |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kirill Reshke <reshkekirill(at)gmail(dot)com> writes:
> On Sun, 17 Aug 2025 at 19:33, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.
Well, if you're inside WaitEventSetWaitBlock, you have little control
over how long you're going to sit. There is a separate discussion
to be had over whether we should prohibit calling that function
inside a critical section. 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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Sami Imseih | 2025-08-18 16:53:44 | Re: Improve LWLock tranche name visibility across backends |
Previous Message | Filip Janus | 2025-08-18 16:51:57 | Re: Proposal: Adding compression of temporary files |