Tom Lane-2 wrote
> legrand legrand <
> legrand_legrand@
> > writes:
>> So the only solution is to had queryId to ErrorData in this hook
>> or create a new hook fired on ERROR and containing queryId ?
>
> I see no particular need for a new hook. What's needed here is for
> pgss_ExecutorRun (and maybe some other existing functions in
> pg_stat_statements) to go ahead and record the statement when they catch
> an error thrown out of standard_ExecutorRun, rather than just updating
> the module's nested_level variable and re-throwing.
>
> The hard part here is that you have to be really careful what you do in
> a PG_CATCH block, because the only thing you know for sure about the
> backend's state is that it's not good. Catalog fetches are right out,
> and anything that might itself throw an error had best be avoided as
> well. (Which, among other things, means that examining executor state
> would be a bad idea, and I'm not even sure you'd want to traverse the plan
> tree.)
>
> I'm not convinced that it's practical for pg_stat_statements to make a new
> shared hashtable entry under those constraints. But figuring out how to
> minimize the risks around that is the stumbling block, not lack of a hook.
>
> regards, tom lane
As far as I have been testing this with *cancelled* queries (Cancel,
pg_cancel_backend(), statement_timeout, ...), I haven't found any problem.
Would limiting the PG_CATCH block to thoses *cancelled* queries
and *no other error*, be an alternate solution ?
If yes, is there a way to identify what was the reason of the error when
entering the PG_CATCH block (and point me to any exemple) ?
Thanks in advance.
Regards
PAscal
--
Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
