| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Ayush Tiwari <ayushtiwari(dot)slg01(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org, "noah(at)leadboat(dot)com" <noah(at)leadboat(dot)com> |
| Subject: | Re: [PATCH] postmaster: fix stale PM_STARTUP comment |
| Date: | 2026-04-17 22:54:14 |
| Message-ID: | aeK6Fj9TiQWCcFgN@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Apr 17, 2026 at 07:17:18PM +0530, Ayush Tiwari wrote:
> I've attached a patch, please review and let me know your thoughts.
/*
- * Unexpected exit of startup process (including FATAL exit)
- * during PM_STARTUP is treated as catastrophic. There are no
- * other processes running yet, so we can just exit.
- */
- if (pmState == PM_STARTUP &&
- StartupStatus != STARTUP_SIGNALED &&
- !EXIT_STATUS_0(exitstatus))
The assumption that only the startup process is running while we are
in a PM_STARTUP state is wrong since 7ff23c6d277d, and this exit code
path has been missed the fact that now the checkpointer and the
bgwriter are started during recovery. So this means a backpatch.
Removing the assertion is the right move, yes, there are other
children, so again that's an issue with 7ff23c6d277d. I am planning
to double-check the shutdown sequence while switching to
PM_WAIT_BACKENDS under a PM_STARTUP, just note that bgworkers that use
BgWorkerStart_PostmasterStart cannot request a database connection,
meaning that PM_WAIT_BACKENDS should be pointeless, but perhaps it
makes the whole shutdown flow easier to reason about, as you are
suggesting, as making this path more complicated would lead to the
addition of more postmaster states. Making this code simpler, not
more complicated, is always useful.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Previous Message | Michael Paquier | 2026-04-17 22:00:42 | Re: Minor cleanup of Meson files given that we require 0.57 |