Hi, On 2025-04-14 10:03:28 -0400, Robert Haas wrote: > On Thu, Apr 10, 2025 at 4:05 PM Andres Freund <and...@anarazel.de> wrote: > > I don't know of existing discussion, but it seems rather fundamental to me - > > if either DSA or memory contexts could be inconsistent at a CFI(), how could > > it possibly be safe to interrupt at that point? After all, after an error > > you > > need to be able to reset the memory contexts / release memory in a > > dsa/dshash/whatnot? Memory context reset requires walking over the > > allocations > > made in the context, similar releasing a dsa? > > I think it would be a bit surprising if somebody put a > CHECK_FOR_INTERRUPTS() inside aset.c or similar, but I don't see a > reason why we couldn't end up with one reachable via the DSA code. DSA > calls DSM which depending on dynamic_shared_memory_type might involve > filesystem operations. That's a fairly large amount of code. I admit I > have no particular theory about how CFI could be reachable from there > today, but even if it definitely isn't, I don't see why someone would > hesitate to add one in the future.
There very well could be a CFI - but it better be somewhere where the in-memory state is consistent. Otherwise an error inside raised in the CFI would lead the in-memory state inconsistent which then would cause problems when cleaning up the dsa during resowner release or process exit. What am I missing here? Greetings, Andres Freund
