From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Maksim Milyutin <m(dot)milyutin(at)postgrespro(dot)ru> |
Cc: | Oleksandr Shulgin <oleksandr(dot)shulgin(at)zalando(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [WIP] Patches to enable extraction state of query execution from external session |
Date: | 2016-09-01 15:58:12 |
Message-ID: | 24182.1472745492@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Maksim Milyutin <m(dot)milyutin(at)postgrespro(dot)ru> writes:
>> On Tue, Aug 30, 2016 at 9:34 AM, Maksim Milyutin
>> <m(dot)milyutin(at)postgrespro(dot)ru <mailto:m(dot)milyutin(at)postgrespro(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2016-09-01 16:02:47 | Re: PostgreSQL 10 kick-off |
Previous Message | Fabrízio de Royes Mello | 2016-09-01 15:44:16 | Re: PostgreSQL 10 kick-off |