| From: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz> |
| 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-09-30 02:23:12 |
| Message-ID: | CAJTYsWXCLi00cJ6-_OkMJB4UjyV6EZjc86QwmgE9=iH_C0R-Aw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Wed, 30 Sept 2026 at 06:32, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
>
> On Wed, Sep 30, 2026 at 05:44:16AM +0530, Ayush Tiwari wrote:
> > I think that argues for the smaller fix, at least on the back branches.
> > I'd tried the diff below[1] before clearing FatalError: it SIGQUITs the new
> > children on smart/fast shutdown, without changing the crash-restart
> > behavior. It fixed my repro on 46024c573bc, though it logs an abnormal
> > shutdown.
>
> Yeah, I can see that, due to this part I think because the FatalError
> flag would be set? Quoting the relevant part from postmaster.c:
> if (Shutdown > NoShutdown && pmState == PM_NO_CHILDREN)
> {
> if (FatalError)
> {
> ereport(LOG, (errmsg("abnormal database system shutdown")));
> ExitPostmaster(1);
> }
> else
> {
> /*
> * Normal exit from the postmaster is here. We don't need to log
> * anything here, since the UnlinkLockFiles proc_exit callback
> * will do so, and that should be the last user-visible action.
> */
> ExitPostmaster(0);
> }
> }
>
> So that just feels, err, okay-ish, because the logs reflect what we
> are actually doing?
>
> So plugging in an extra HandleFatalError() while the pmState is
> PM_STOP_BACKENDS feels like a good compromise, on top of my mind. It
> would mean that your too-early-shutdown request on crash recovery
> would still persist on v17 and older branches, but at least the
> checkpointer and the I/O workers would be able to understand that they
> need to stop, and the SIGQUIT sent would be promoted to a SIGKILL
> after the AbortStartTime timeout is armed.
Thanks, I've gone back to the smaller fix in v2 (attached), leaving the
FatalError reset where it was.
> I was slightly on the edge about your TAP test and its fancy restore
> command, but I don't want to leave that untested, either [...]
I've kept the helper, but now wait for the new checkpointer to install its
signal handlers. The helper gets more time too.
> Perhaps only do that on HEAD first, let it brew for a bit, and consider
> it down later on if really necessary?
You have a better feel for the backpatch risk here, so I'll defer to you..
Regards,
Ayush
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-shutdown-during-crash-restart.patch | application/octet-stream | 5.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bharath Rupireddy | 2026-09-30 02:45:00 | Re: Parallel autovacuum: DROP DATABASE WITH (FORCE) fails on the parallel workers |
| Previous Message | Tom Lane | 2026-09-30 02:21:03 | Do we need to back-patch tzcode 2026b after all? |