Re: lazy vxid locks, v3

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: lazy vxid locks, v3
Date: 2011-08-01 00:32:21
Message-ID: 1312158741.29391.75.camel@jdavis
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Wed, 2011-07-20 at 13:41 -0400, Robert Haas wrote:
> I took another look at v2 of my lazy vxid locks patch and realized
> that it was pretty flaky in a couple of different ways. Here's a
> version that I think is a bit more robust, but considering the extent
> of the revisions, it probably needs another round of review from
> someone before I commit it.
> Any review appreciated; I would prefer not to have to wait until
> October to get this committed, since there is quite a bit of follow-on
> work that I would like to do as well. FWIW, the performance
> characteristics are basically identical to the previous versions,

fpLocalTransactionId is redundant with the lxid, and the explanation is
that one that they have different locking semantics. That looks
reasonable, and it avoided the need for the careful ordering while
starting/ending a transaction that was present in v2.

However, it also looks like you're using it for another purpose:

In VirtualXactLockTableCleanup():
* If fpVXIDLock has been cleared without touching fpLocalTransactionId,
* that means someone transferred the lock to the main lock table.
if (!fastpath && LocalTransactionIdIsValid(lxid))

Is the "&& LocalTransactionIdIsValid(lxid)" a guard against calling
VirtualXactLockTableCleanup twice? Can that happen? Or is it just
defensive coding to avoid making an additional assumption?

Jeff Davis

PS: In the recent sinval synch patch, you had a typo: "If we haven't
catch up completely". Other than that, it looked good.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2011-08-01 01:49:03 Re: SSI heap_insert and page-level predicate locks
Previous Message Andrew Dunstan 2011-07-31 23:28:16 Re: python cleanup