Tom Lane-2 wrote > legrand legrand < > legrand_legrand@ > > writes: >> Tom Lane-2 wrote >>> 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. > >> 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 ? > > I do not see that that would make one iota of difference to the risk that > the executor state tree is inconsistent at the instant the error is > thrown. You can't test your way to the conclusion that it's safe, either > (much less that it'd remain safe); your test cases surely haven't hit > every CHECK_FOR_INTERRUPTS call in the backend. > > regards, tom lane new try: Considering that executor state tree is limited to QueryDesc->estate, that would mean that rows processed can not be trusted, but that queryid, buffers and *duration* (that is the more important one) can still be used ? Knowing that shared hashtable entries are now (in pg13) created during planning time. There is no need to create a new one for execution error: just update counters (current ones or new columns like "errors" , "total_error_time", ... added to pg_stat_statements view). Is that better ? Regards PAscal -- Sent from: https://www.postgresql-archive.org/PostgreSQL-general-f1843780.html
