On Mon, Feb 17, 2025 at 4:01 PM Andres Freund <andres@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
