From: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>
To: Kevin Grittner <Kevin.Grittner@wicourts.gov>
Cc: drkp@csail.mit.edu
Cc: pgsql-hackers@postgresql.org
Subject: Re: Repeated PredicateLockRelation calls during seqscan
Date: Sun, 26 Jun 2011 16:05:45 +0300
Message-ID: <4E072EA9.3030200@enterprisedb.com> (raw)
In-Reply-To: <4E05F0D2020000250003EC1D@gw.wicourts.gov>
References: <4E05F0D2020000250003EC1D@gw.wicourts.gov>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: heikki.linnakangas@enterprisedb.com, Kevin.Grittner@wicourts.gov, drkp@csail.mit.edu
Subject: Re: Repeated PredicateLockRelation calls during seqscan
In-Reply-To: <4E072EA9.3030200@enterprisedb.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox