Message-ID: <4E072EA9.3030200@enterprisedb.com>
Date: Sun, 26 Jun 2011 16:05:45 +0300
From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; fi-FI;
	rv:1.9.2.17) Gecko/20110606 Icedove/3.1.10
MIME-Version: 1.0
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
CC: drkp@csail.mit.edu, pgsql-hackers@postgresql.org
Subject: Re: Repeated PredicateLockRelation calls during seqscan
References: <4E05F0D2020000250003EC1D@gw.wicourts.gov>
In-Reply-To: <4E05F0D2020000250003EC1D@gw.wicourts.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 25.06.2011 22:29, Kevin Grittner wrote:
> In looking this over I noticed something else that doesn't seem quite
> right.  In heapam.c there are two places where the execution of
> PredicateLockTuple() is conditioned not just on MVCC visibility, but
> also on HeapKeyTest().  I think those calls should be moved to not be
> conditioned on that.  Otherwise we have a predicate condition being
> tested without "locking the gaps", don't we?

Locks on heap tuples don't serve the purpose of locking gaps, anyway, 
because you can't lock anything that doesn't yet exist that way. Locks 
on index pages and the heap relation serve that purpose.

I wonder if we need those PredicateLockTuple() calls in heapam.c at all. 
You need to take a whole-relation lock on the heap to lock the gaps, to 
ensure that you conflict newly inserted rows. And if fetch a tuple via 
an index, you acquire locks on the index pages. What is the point of the 
PredicateLockTuple() calls? We added the rs_relpredicatelocked mechanism 
as an optimization, but I'm thinking that it's actually required for 
correctness to grab a predicate lock on the whole relation when you do a 
seqscan.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com