From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: reducing the overhead of frequent table locks, v4 |
Date: | 2011-07-10 21:15:55 |
Message-ID: | 1310332555.3012.251.camel@jdavis |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-07-10 22:06:22 | Re: Patch Review: Bugfix for XPATH() if text or attribute nodes are selected |
Previous Message | Peter Eisentraut | 2011-07-10 20:23:58 | Re: Re: Proposed Windows-specific change: Enable crash dumps (like core files) |