Re: [PATCH] Clear FatalError earlier during crash restart

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Noah Misch <noah(at)leadboat(dot)com>
Subject: Re: [PATCH] Clear FatalError earlier during crash restart
Date: 2026-10-07 00:07:06
Message-ID: asWNKpf8HbXmJGJe@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 01, 2026 at 10:54:55AM +0530, Ayush Tiwari wrote:
> Thanks for this. The patch looks good to me.
> I did multiple A/B testing and it works well.

I've been going back and forth a bit in the postmaster code to try
more if FatalError can be made again non-re-entrant for
HandleFatalError() with an assertion. My first try was the
introduction of a new flag to track if SIGQUIT was sent, but I was not
completely sure that I got the semantics right. A second set of
thoughts was pointing towards a more complicated scheme for the
states, which felt not really exciting. At the end, I have just
reused your solution, and applied it on HEAD. Let's let it brew first
there. The lack of complaints on the matter (even if we had one back
in 2023), and the v19 release being very close by don't argue in favor
of a backpatch, at least it feels strongly so to me.

Now down to the buildfarm to judge the stability of your test. The CI
has cleared quite a few times.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2026-10-07 00:40:56 Re: [PG19] eager aggregation gives wrong results because of bpchar_ops
Previous Message Peter Geoghegan 2026-10-06 23:54:33 Re: [PG19] eager aggregation gives wrong results because of bpchar_ops