On Jul 10, 2011, at 4:15 PM, Jeff Davis <pg...@j-davis.com> wrote: > On Mon, 2011-06-27 at 10:13 -0400, Robert Haas wrote: >> I didn't get a lot of comments on my the previous version of my patch >> to accelerate table locks. >> >> http://archives.postgresql.org/pgsql-hackers/2011-06/msg00953.php >> >> Here's a new version anyway. In this version, I have: > > I am trying to figure out holdsStrongLockCount. It's declared as an > integer, but (unless cscope is failing me) is only ever set to 0 or 1. > It's never incremented or decremented. It looks like it's supposed to be > a boolean indicating that the lock should decrement something in > FastPathStrongLocks when released.
Yes. > Furthermore, in AtPrepare_Locks(), the comment says: > > /* > * Arrange not to release any strong lock count held by this lock > * entry. We must retain the count until the prepared transaction > * is committed or rolled back. > */ > locallock->holdsStrongLockCount = 0; > > But doesn't seem to "arrange" much, as far as I can tell. Well, it arranges not to release the strong lock count when the LOCALLOCK is nuked; instead, we need to release it when the final COMMIT PREPARED or ROLLBACK PREPARED happens. > I think the 2PC code is still correct, because it infers from the > lockmode that the FastPathStrongLocks counter needs to be incremented. > However, why doesn't other code (RemoveLocalLock is the only reader) > make a similar inference? Because you could hit an ERROR in LockAcquire, and you need to know, at the time you clean up the LOCALLOCK, whether or not a strong lock count had been acquired. I didn't originally have holdsStrongLockCount, but it seemed really fragile that way. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
