Re: Parallel query vs smart shutdown and Postmaster death

Hi,

Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:

> 1. Why does pmdie()'s SIGTERM case terminate parallel workers
> immediately? That breaks aborts running parallel queries, so they
> don't get to end their work normally.
> 2. Why are new parallel workers not allowed to be started while in
> this state? That hangs future parallel queries forever, so they don't
> get to end their work normally.
> 3. Suppose we fix the above cases; should we do it for parallel
> workers only (somehow), or for all bgworkers? It's hard to say since
> I don't know what all bgworkers do.

Attached patch fixes 1 and 2. As for the 3, the only other internal
bgworkers currently are logical replication launcher and workers, which
arguably should be killed immediately.

> Here's an initial sketch of a
> patch like that: it gives you "ERROR: parallel worker failed to
> initialize" and "HINT: More details may be available in the server
> log." if you try to run a parallel query.

Reporting bgworkers that postmaster is never going to start is probably
worthwhile doing anyway to prevent potential further deadlocks like
this. However, I think there is a problem in your patch: we might be in
post PM_RUN states due to FatalError, not because of shutdown. In this
case, we shouldn't refuse to run bgws in the future. I would also merge
the check into bgworker_should_start_now.

--
Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company