On Thu, Jul 21, 2011 at 5:56 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> Instead of leaving the locks dangling to an already-destroyed resource
>> owner, how about assigning all locks directly to the top-level resource
>> owner in one sweep? That'd still be much better than the old way of
>> recursively reassigning them up the subtransaction tree, one level at a
>> time.
>
> I haven't actually read the patch, but the reason for pushing them up
> only one level at a time is that if an intermediate-level subtransaction
> aborts, the locks taken by its child subtransactions have to be released
> at that time. It sure sounds like this patch broke that.
The only path altered by the patch was the
final-commit-while-in-a-subxact, so I don't see a problem in the part
you mention.
At commit all the locks get transferred to the parent, so we scan the
the lock table repeatedly, giving O(N^2).
I think I'll just revert it though. Subtransactions need a lot of
tuning but this isn't high enough up my list to be worth the work.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services