On Thu, Jul 21, 2011 at 5:56 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <heikki.linnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
