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