01.09.2016 18:58, Tom Lane пишет:
Maksim Milyutin <m.milyu...@postgrespro.ru> writes:
On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin
<m.milyu...@postgrespro.ru <mailto:m.milyu...@postgrespro.ru>> wrote:
Yes, but the problem is that nothing gives you the guarantee that at the
moment you decide to handle the interrupt, the QueryDesc structures
you're looking at are in a good shape for Explain* functions to run on
them. Even if that appears to be the case in your testing now, there's
no way to tell if that will be the case at any future point in time.
CHECK_FOR_INTERRUPTS are located in places where query state (QueryDesc
structure) is more or less consistent.
Really? Even if that's 100% true today, which I wouldn't bet very much
on, it seems like a really dangerous property to insist on system-wide.
The only restriction we have ever placed on CHECK_FOR_INTERRUPTS is that
it occur at places where it'd be safe to throw elog(ERROR), and in general
we don't assume that the active query is still in a usable state after
an error. What you propose would amount to a new restriction that nothing
can ever call any nontrivial subroutine while the active query tree is
less than fully valid (because the subroutine might contain a
CHECK_FOR_INTERRUPTS somewhere). That sounds impractical and
unenforceable.
Ok, thanks! I could propose a different approach: when
CHECK_FOR_INTERRUPTS occurs, set a hook to be executed by the following
ExecProcNode(). The hook is going to be provided by my extension. It is
expected to send current query state to some recipient backend (the one
who asked for it). I think the active query is consistent after any node
have worked off one or zero rows. After it has sent all necessary data,
the hook will disable itself.
--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
