Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
От | Zeugswetter Andreas DCP SD |
---|---|
Тема | Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work) |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA5790116BC19@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
> >> This bothers me a bit, because in > >> fact the effects if any of the tested query would have been rolled > >> back. Not sure we have any choice though. If we expose the error > >> then we'll have problems with clients not showing the EXPLAIN > >> results. > > > I think we should leave it in top level, throw the error and fix the > > clients. > > As I understood, the idea was, that it only does that if you press ^C > > or query timeout. In this case current clients would also not show the > > plan. > > Not if the clients are implemented per protocol spec. A > client cannot assume that sending QueryCancel will make the > current query fail. Sorry I don't understand that comment. I did not not say that it must fail, but iff it is interrupted (and thus fails) was the case I meant. You stated, that current clients won't show the explain output if they get a protocol error response. (Does the protocol not allow both data and error ?) We would need to teach clients to output the explain result even if an error is returned. I hold my comment: on ^C we should return the plan and return the error. We should not misuse automatic subtransactions for this. Andreas
В списке pgsql-hackers по дате отправления: