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
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. |