On Tue, Nov 25, 2025 at 11:25:09AM -0500, Robert Haas wrote:
> The downside is that then we have to rely on PG_CATCH() to make things
> whole. I am not sure that there's any problem with that, but I'm also
> not sure that there isn't. The timing of PG_CATCH() block execution
> often creates bugs, because it runs before (sub)transaction abort.
> That means that there's a real risk that you try to acquire an LWLock
> you already hold, for example. It's a lot easier to be confident that
> cleanup actions will reliably succeed when they run inside the
> transaction abort path that knows the order in which various resources
> should be released. Generally, I think it's PG_CATCH() is fine if
> you're releasing a resource that is decoupled from everything else,
> like using a third-party library's free function to free memory
> allocated by that library. But if you're releasing PostgreSQL
> resources that are layered on top of other PostgreSQL resources, like
> a DSA that depends on DSM and LWLock, I think it's a lot more
> difficult to be certain that you aren't going to end up trying to
> release the same stuff multiple times or in the wrong order. I'm not
> saying you can't make it work, but I've banged my head on this
> particular doorframe enough times that my reflex is to duck.
I gave your idea a try, and I like the result a lot. IMHO it makes the
code much easier to reason about.
--
nathan