]> granicus.if.org Git - postgresql/commit
Fix serializable mode with index-only scans.
authorKevin Grittner <kgrittn@postgresql.org>
Wed, 5 Sep 2012 02:14:25 +0000 (21:14 -0500)
committerKevin Grittner <kgrittn@postgresql.org>
Wed, 5 Sep 2012 02:14:25 +0000 (21:14 -0500)
commit3e22659e0cb2181d71818eea96dc831a7e37cd69
tree6067a8b0c0350a415627e350c84d5cd80b443b68
parent8e39fd97f1566820f7dfd2b4d36dc6bd41211747
Fix serializable mode with index-only scans.

Serializable Snapshot Isolation used for serializable transactions
depends on acquiring SIRead locks on all heap relation tuples which
are used to generate the query result, so that a later delete or
update of any of the tuples can flag a read-write conflict between
transactions.  This is normally handled in heapam.c, with tuple level
locking.  Since an index-only scan avoids heap access in many cases,
building the result from the index tuple, the necessary predicate
locks were not being acquired for all tuples in an index-only scan.

To prevent problems with tuple IDs which are vacuumed and re-used
while the transaction still matters, the xmin of the tuple is part of
the tag for the tuple lock.  Since xmin is not available to the
index-only scan for result rows generated from the index tuples, it
is not possible to acquire a tuple-level predicate lock in such
cases, in spite of having the tid.  If we went to the heap to get the
xmin value, it would no longer be an index-only scan.  Rather than
prohibit index-only scans under serializable transaction isolation,
we acquire an SIRead lock on the page containing the tuple, when it
was not necessary to visit the heap for other reasons.

Backpatch to 9.2.

Kevin Grittner and Tom Lane
src/backend/executor/nodeIndexonlyscan.c
src/test/isolation/expected/index-only-scan.out [new file with mode: 0644]
src/test/isolation/isolation_schedule
src/test/isolation/specs/index-only-scan.spec [new file with mode: 0644]