Index-only scans and non-MVCC snapshots

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.