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
