Re: Parallel query vs smart shutdown and Postmaster death

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Parallel query vs smart shutdown and Postmaster death
Date: 2019-02-27 15:38:46
Message-ID: CA+Tgmobub0+BYs0F4tMHHV2ysuJWsY=b98MjMBnttErWLrBZ8A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Feb 26, 2019 at 5:44 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-02-27 15:46:23 Re: Unneeded parallel safety tests in grouping_planner
Previous Message Dilip Kumar 2019-02-27 15:35:01 Re: some hints to understand the plsql cursor.