Skip site navigation (1) Skip section navigation (2)

Re: lazy vxid locks, v3

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: lazy vxid locks, v3
Date: 2011-08-01 12:12:42
Message-ID: CA+TgmoY03sEwAHQpxrBjf+RWzGkD1QhX0rM-5wMaBZ0ssLECCg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sun, Jul 31, 2011 at 8:32 PM, Jeff Davis <pgsql(at)j-davis(dot)com> wrote:
> 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.

...which I became fairly convinced was in fact insufficiently careful.

> 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?

lxid there is just a local variable storing the value that we
extracted from fpLocalTransactionId while holding the lock.  I named
it that way just as a mnemonic for the type of value that it was, not
intending to imply that it was copied from MyProc->lxid.

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

Ah, thanks.  Will fix.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

pgsql-hackers by date

Next:From: Heikki LinnakangasDate: 2011-08-01 13:29:42
Subject: Re: Hot standby and GiST page splits (was Re: WIP: Fast GiST index build)
Previous:From: Florian PflugDate: 2011-08-01 12:01:29
Subject: Re: Access to current database from C-language function

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group