legrand legrand <legrand_legrand@hotmail.com> 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
