legrand legrand <legrand_legrand@xxxxxxxxxxx> 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
