On Fri, Feb 23, 2024 at 7:50 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > On Fri, Feb 23, 2024 at 10:22:32AM +0530, Robert Haas wrote: > > On Thu, Feb 22, 2024 at 6:25 AM James Coleman <jtc...@gmail.com> wrote: > > > This is potentially a bit of a wild idea, but I wonder if having some > > > kind of argument to CHECK_FOR_INTERRUPTS() signifying we're in > > > "normal" as opposed to "critical" (using that word differently than > > > the existing critical sections) would be worth it. > > > > It's worth considering, but the definition of "normal" vs. "critical" > > might be hard to pin down. Or, we might end up with a definition that > > is specific to this particular case and not generalizable to others. > > But it doesn't have to be all or nothing right? I mean each call could say > what the situation is like in their context, like > CHECK_FOR_INTERRUPTS(GUARANTEE_NO_HEAVYWEIGHT_LOCK | GUARANTEE_WHATEVER), and > slowly tag calls as needed, similarly to how we add already CFI based on users > report.
Absolutely. My gut feeling is that it's going to be simpler to pick a small number of places that are safe and sufficient for this particular feature and add an extra call there, similar to how we do vacuum_delay_point(). The reason I think that's likely to be better is that it will likely require changing only a relatively small number of places. If we instead start annotating CFIs, well, we've got hundreds of those. That's a lot more to change, and it also inconveniences third-party extension authors and people doing back-patching. I'm not here to say it can't work; I just think it's likely not the easiest path. -- Robert Haas EDB: http://www.enterprisedb.com
