Re: reducing the overhead of frequent table locks, v4

On Jul 10, 2011, at 4:15 PM, Jeff Davis <pgsql(at)j-davis(dot)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