01.09.2016 18:58, Tom Lane пишет:
> Maksim Milyutin <m.milyutin@postgrespro.ru> writes:
>>> On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin
>>> <m.milyutin@postgrespro.ru <mailto:m.milyutin@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
