Thread: Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
From
"Zeugswetter Andreas DCP SD"
Date:
> 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. Andreas
Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
From
Tom Lane
Date:
"Zeugswetter Andreas DCP SD" <ZeugswetterA@spardat.at> writes: >> 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. regards, tom lane
Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
From
"Zeugswetter Andreas DCP SD"
Date:
> >> 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