Hi, On 2023-01-04 17:55:43 -0500, Tom Lane wrote: > I'm not very happy with this line of development at all, because I think we > are painting ourselves into a corner by not allowing code to detect whether > a cancel is pending without having it happen immediately. (That is, I do > not believe that backend/regex/ is the only code that will ever wish for > that.)
I first wrote that this is hard to make work without introducing overhead (like a PG_TRY in rcancelrequested()), for a bunch of reasons discussed upthread (see [1]). But now I wonder if we didn't recently introduce most of the framework to make this less hard / expensive. What about using a version of errsave() that can save FATALs too? We could have something roughly like the ProcessInterrupts() in the proposed patch that is used from within rcancelrequested(). But instead of actually throwing the error, we'd just remember the to-be-thrown-later error, that the next "real" CFI would throw. That still leaves us with some increased likelihood of erroring out within the regex machinery, e.g. if there's an out-of-memory error within elog.c processing. But I'd not be too worried about leaking memory in that corner case. Which also could be closed using the approach in Thomas' patch, except that it normally would still return in rcancelrequested(). Insane? Greetings, Andres Freund [1] https://postgr.es/m/CA%2BhUKG%2BqtNxDQAzC20AnUxuigKYb%3D7shtmsuSyMekjni%3Dik6BA%40mail.gmail.com
