Tatsuo Ishii <t-ishii@sra.co.jp> writes:
>> What I propose doing about it is modifying lo_commit to destroy
>> lo_open's private memory context. This will mean going back to the
>> old semantics wherein large object descriptors are not valid across
>> transactions. But I think that's the safest thing anyway.
> Then why should we use the private memory context if all lo operations
> must be in a transaction?
Right now, we could dispense with the private context. But I think
it's best to leave it there for future flexibility. For example, I was
thinking about flushing the context only if no LOs remain open (easily
checked since lo_commit scans the cookies array anyway); that would
allow cross-transaction LO handles without imposing a permanent memory
leak. The trouble with that --- and this is a bug that was there anyway
--- is that you need some way of cleaning up LO handles that are opened
during an aborted transaction. They might be pointing at an LO relation
that doesn't exist anymore. (And even if it does, the semantics of xact
abort are supposed to be that all side effects are undone; opening an LO
handle would be such a side effect.)
As things now stand, LO handles are always closed at end of transaction
regardless of whether it was commit or abort, so there is no bug.
We could think about someday adding the bookkeeping needed to keep track
of LO handles opened during the current xact versus ones already open,
and thereby allow them to live across xact boundaries without risking
the bug. But that'd be a New Feature so it's not getting done for 6.5.
regards, tom lane