Hi,

As part of a research project, I'm trying to change Read Committed isolation to use HeapTupleSatisfiesNow rather than acquiring a new snapshot at every command [1]. Things appear to have gone reasonably well so far, except certain queries fail with "ERROR: non-MVCC snapshots are not supported in index-only scans."


I'm using v9.3.2, and the docs claim that index-only scans work without MVCC, but require some extra locking to avoid races [2]. Is this not actually implemented? If that is the case, shouldn't the query optimizer avoid selecting index-only scans for non-MVCC snapshots?

I realize I'm playing with fire here, but any pointers to sections of code I might look at to either work around or fix this issue would be greatly appreciated. I've been looking around in index_fetch_heap (indexam.c) as well as other locations that use scan->xs_continue_hot; there seems to be code in place to detect when a non-MVCC snapshot is in use, as if that were nothing out of the ordinary, but nothing prevents the error from arising if a hot chain is actually encountered.

Thanks,
Ryan

[1] Right now, Read Committed is significantly *slower* than Repeatable Read---for transactions involving multiple short commands---because the former acquires multiple snapshots per transaction and causes a lwlock bottleneck on my 12-core machine.

[2] http://www.postgresql.org/docs/9.3/static/index-locking.html:
with a non-MVCC-compliant snapshot (such as SnapshotNow), it would be possible to accept and return a row that does not in fact match the scan keys ... [so] we use a pin on an index page as a proxy to indicate that the reader might still be "in flight" from the index entry to the matching heap entry. Making ambulkdelete block on such a pin ensures that VACUUM cannot delete the heap entry before the reader is done with it. ... This solution requires that index scans be "synchronous": we have to fetch each heap tuple immediately after scanning the corresponding index entry. This is expensive for a number of reasons. An "asynchronous" scan in which we collect many TIDs from the index, and only visit the heap tuples sometime later, requires much less index locking overhead and can allow a more efficient heap access pattern. Per the above analysis, we must use the synchronous approach for non-MVCC-compliant snapshots.



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to