Re: Parallel query hangs after a smart shutdown is issued

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>
Subject: Re: Parallel query hangs after a smart shutdown is issued
Date: 2020-08-12 20:59:28
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> Oh, excellent point! I'd not thought to look at tests of the Shutdown
> variable, but yeah, those should be <= SmartShutdown if we want autovac
> to continue to operate in this state.

On looking closer, there's another problem: setting start_autovac_launcher
isn't enough to get the AV launcher to run, because ServerLoop() won't
launch it except in PM_RUN state. Likewise, the other "relaunch a dead
process" checks in ServerLoop() need to be generalized to support
relaunching background processes while we're waiting out the foreground
clients. So that leads me to the attached v3. I had to re-instantiate
PM_WAIT_READONLY as an alternate state to PM_WAIT_CLIENTS; these states
are about the same so far as PostmasterStateMachine is concerned, but
some of the should-we-launch-FOO checks care about the difference.

The various pmState tests are getting messy enough to cry out for
refactorization, but I've not attempted that here. There's enough
variance in the conditions for launching different subprocesses that
I'm not very sure what would be a nicer-looking way to write them.

regards, tom lane

Attachment Content-Type Size
keep-bg-processes-alive-in-smart-shutdown-3.patch text/x-diff 12.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2020-08-12 21:41:42 Re: Parallel query hangs after a smart shutdown is issued
Previous Message Alvaro Herrera 2020-08-12 19:58:19 Re: [BUG] Error in BRIN summarization