On Jul 10, 2011, at 4:15 PM, Jeff Davis <pgsql@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
thefinal 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
nota strong lock count had been acquired. I didn't originally have holdsStrongLockCount, but it seemed really fragile
thatway.
...Robert
