On Mon, Feb 17, 2025 at 4:01 PM Andres Freund <and...@anarazel.de> wrote: > If one instead integrates with resowners, that kind of thing works, because > exec_simple_query() calls PortalDrop(), which in turn calls > ResourceOwnerRelease().
Hmm, so maybe that's a reason to do it via resowner.c, then. The fact that it's a singleton object is a bit annoying, but you could make it not a singleton, and then either pass the relevant one to the interface functions, or store the current one in a global variable similar to CurrentMemoryContext or similar. > I guess I could just put something alongside that CommandCounterIncrement() > call, but that doesn't seem right. I guess putting it alongside the > ResourceOwnerRelease() in PortalDrop() is a bit less bad? But still doesn't > seem great. The thing that's weird about that is that it isn't really logically linked to the portal. It feels like it more properly belongs in StartTransactionCommand() / CommitTransactionCommand(). > Just using resowners doesn't seem right either, it's not really free to > register something with resowners, and for read intensive IO we can start a > *lot* of batches, so doing unnecessary work isn't great. You don't necessarily have to register a new object for every batch, do you? You could just register one and keep reusing it for the lifetime of the query. -- Robert Haas EDB: http://www.enterprisedb.com
