Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Here is a patch that fixes some of the TODO items in the nested xacts
> list:
> handle large objects
On the large-objects stuff: it seems like a really bad idea to be
fooling with CurrentResourceOwner like that. What that means is that if
a subtransaction opens a LO and then fails, the associated low-level
resources will remain allocated until the top transaction ends ... even
though the LargeObjectDesc went away in subtransaction abort. In the
worst case with repeated retries, it seems like this could run you out
of free buffers, for example.
It occurs to me that the only resource held for any long period in this
code is the open relations (heap_r and index_r), and that it's pretty
silly to have every open LO have its own reference to pg_largeobject.
(I believe the code in inv_api.c is a holdover from a time when LOs
could live in different tables; but that's been dead for a long time
and seems quite unlikely to get resurrected.)
Also, there's no urgent need to maintain a distinction between read and
write access in terms of the kind of lock we take on pg_largeobject.
There aren't any operations that anyone should be performing on
pg_largeobject that would care about the difference between
AccessShareLock and RowExclusiveLock.
This means that upon first use of any LO within a main transaction,
we can open pg_largeobject *once* and use it for all LOs for the rest
of the transaction. This reference would be okay to assign to the top
ResourceOwner. The resources acquired and released during inv_read,
inv_write, etc, can be left with the normal CurrentResourceOwner so that
they'll be dropped immediately in case of error.
Any comments on this plan?
regards, tom lane