Re: reducing the overhead of frequent table locks, v4 - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: reducing the overhead of frequent table locks, v4
Date
Msg-id 1310332555.3012.251.camel@jdavis
Whole thread Raw
In response to reducing the overhead of frequent table locks, v4  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: reducing the overhead of frequent table locks, v4
List pgsql-hackers
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.

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.

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?

Can we just get rid of holdsStrongLockCount completely?

Regards,Jeff Davis



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files)
Next
From: Robert Haas
Date:
Subject: Re: Patch Review: Bugfix for XPATH() if text or attribute nodes are selected