Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> Regarding the lock mechanism, I simply added some code to LockReleaseAll
> so it gets the array of committed child Xids; on subtransaction abort,
> the whole lock struct is scanned just like it's done on main transaction
> abort; only those locks affiliated with one of the given Xids are
> released. This is naive, so if it's incorrect please comment.
Another and perhaps simpler way would be to leave the release code
alone, but on subtransaction commit scan through the lock structs
and re-mark locks held by the subtrans as being held by the parent.
I think these are isomorphic functionally. The second way feels like
it would be faster (no inner loop over child XIDs). On the other hand,
if your current code does not require scanning the lock structures at
all on subtrans commit, it's probably not a win to add such a scan.
The lock algorithms must be able to tell when two lock requests are
coming from the same backend. At present I think this relies on
comparing XIDs, which is not going to work if you label subtrans locks
with subtrans XIDs. How are you thinking about handling that?
regards, tom lane
