Re: On-demand running query plans using auto_explain and signals - Mailing list pgsql-hackers

From Robert Haas
Subject Re: On-demand running query plans using auto_explain and signals
Date
Msg-id CA+TgmoZ80Nu4yQCPE9D0Y7u8_Hs1a2c-vRJmLueTn68U16Ln6g@mail.gmail.com
Whole thread Raw
In response to Re: On-demand running query plans using auto_explain and signals  ("Shulgin, Oleksandr" <oleksandr.shulgin@zalando.de>)
List pgsql-hackers
On Tue, Sep 29, 2015 at 1:52 PM, Shulgin, Oleksandr
<oleksandr.shulgin@zalando.de> wrote:
> This is not a change of the direction, but rather of the approach.  Hitting
> a process with a signal and hoping it will produce a meaningful response in
> all circumstances without disrupting its current task was way too naive.

I think that's exactly right.  It's not safe to do much anything from
a signal handler, and while ProcessInterrupts() is a very
substantially safer, the set of things that can be safely done there
is still awfully restricted.  You have to cope with the fact that the
function you just interrupted may be doing anything at all, and if you
change anything before returning, you may knock over the apple cart.
Just as bad, the state you inherit may not be very sane: we call
ProcessInterrupts() from LOTS of places and there is absolutely no
guarantee that every one of those places has the data structures that
you need to run EXPLAIN ANALYZE in a sane state.

I haven't looked at the new patch specifically so I don't have an
opinion on that at this time.

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PROPOSAL] VACUUM Progress Checker.
Next
From: Alvaro Herrera
Date:
Subject: Re: Request for dogfood volunteers (was No Issue Tracker - Say it Ain't So!)