pgsql: Move the PredicateLockRelation() call from nodeSeqscan.c to heap

From: Heikki Linnakangas <heikki(dot)linnakangas(at)iki(dot)fi>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Move the PredicateLockRelation() call from nodeSeqscan.c to heap
Date: 2011-06-29 19:16:37
Message-ID: E1Qc0FZ-00005d-1H@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Move the PredicateLockRelation() call from nodeSeqscan.c to heapam.c. It's
more consistent that way, since all the other PredicateLock* calls are
made in various heapam.c and index AM functions. The call in nodeSeqscan.c
was unnecessarily aggressive anyway, there's no need to try to lock the
relation every time a tuple is fetched, it's enough to do it once.

This has the user-visible effect that if a seq scan is initialized in the
executor, but never executed, we now acquire the predicate lock on the heap
relation anyway. We could avoid that by taking the lock on the first
heap_getnext() call instead, but it doesn't seem worth the trouble given
that it feels more natural to do it in heap_beginscan().

Also, remove the retail PredicateLockTuple() calls from heap_getnext(). In
a seqscan, started with heap_begin(), we're holding a whole-relation
predicate lock on the heap so there's no need to lock the tuples
individually.

Kevin Grittner and me

Branch
------
REL9_1_STABLE

Details
-------
http://git.postgresql.org/pg/commitdiff/f01e3d3a414f909762ab840719aeb8ae291aab5a

Modified Files
--------------
src/backend/access/heap/heapam.c | 21 ++++++++++++++-------
src/backend/executor/nodeSeqscan.c | 6 ------
src/include/access/relscan.h | 1 -
3 files changed, 14 insertions(+), 14 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Michael Paquier 2011-06-29 23:11:33 Re: [COMMITTERS] pgsql: Branch refs/heads/REL9_1_STABLE was removed
Previous Message Heikki Linnakangas 2011-06-29 19:16:36 pgsql: Move the PredicateLockRelation() call from nodeSeqscan.c to heap