Re: Parallel query vs smart shutdown and Postmaster death - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Parallel query vs smart shutdown and Postmaster death
Date
Msg-id CA+Tgmobub0+BYs0F4tMHHV2ysuJWsY=b98MjMBnttErWLrBZ8A@mail.gmail.com
Whole thread Raw
In response to Re: Parallel query vs smart shutdown and Postmaster death  (Thomas Munro <thomas.munro@gmail.com>)
List pgsql-hackers
On Tue, Feb 26, 2019 at 5:44 PM Thomas Munro <thomas.munro@gmail.com> wrote:
> Then perhaps we could do some more involved surgery on master that
> achieves smart shutdown's stated goal here, and lets parallel queries
> actually run?  Better ideas welcome.

I have noticed before that the smart shutdown code does not disclose
to the rest of the system that a shutdown is in progress: no signals
are sent, and no shared memory state is updated.  That makes it a bit
challenging for any other part of the system to respond to the smart
shutdown in a way that is, well, smart.  But I guess that's not really
the problem in this case.

It seems to me that we could fix pmdie() to skip parallel workers; I
think that the postmaster could notice that they are lagged as
BGWORKER_CLASS_PARALLEL.  But we'd also have to fix things so that new
parallel workers could be launched during a smart shutdown, which
looks not quite so simple.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: some hints to understand the plsql cursor.
Next
From: Robert Haas
Date:
Subject: Re: Unneeded parallel safety tests in grouping_planner