Re: [WIP] Patches to enable extraction state of query execution from external session
От | Tom Lane |
---|---|
Тема | Re: [WIP] Patches to enable extraction state of query execution from external session |
Дата | |
Msg-id | 24182.1472745492@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [WIP] Patches to enable extraction state of query execution from external session (Maksim Milyutin <m.milyutin@postgrespro.ru>) |
Ответы |
Re: [WIP] Patches to enable extraction state of query
execution from external session
|
Список | pgsql-hackers |
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. regards, tom lane
В списке pgsql-hackers по дате отправления: