Fix the one-element tuple visibility cache in heap scans, for multi-xids.
Fix the one-element tuple visibility cache in heap scans, for multi-xids.

It's not cool to use the raw xmax value as part of the cache key. If the
raw xmax represents a multi-xid, the real deleter XID would be something
else. We could get fooled, if we cached a multi-XID value, and later saw
a tuple with a regular xmax, with the same numerical value as the cached
multi-XID.

I think this was actually broken before the 9.3 merge already. If a
transaction locked a tuple, and deleted another tuple, and a concurrent
scan sees the locked tuple first, it might think that the deleted tuple
is also visible to it, because it has the same xmin+xmax combination as
the locked tuple.

adam8157/gpdb,jmcatamney/gpdb,lisakowen/gpdb,adam8157/gpdb,ashwinstar/gpdb,adam8157/gpdb,jmcatamney/gpdb,50wu/gpdb,greenplum-db/gpdb,lisakowen/gpdb,50wu/gpdb,adam8157/gpdb,ashwinstar/gpdb,lisakowen/gpdb,50wu/gpdb,ashwinstar/gpdb,jmcatamney/gpdb,jmcatamney/gpdb,xinzweb/gpdb,xinzweb/gpdb,lisakowen/gpdb,xinzweb/gpdb,greenplum-db/gpdb,50wu/gpdb,jmcatamney/gpdb,adam8157/gpdb,jmcatamney/gpdb,greenplum-db/gpdb,ashwinstar/gpdb,ashwinstar/gpdb,adam8157/gpdb,lisakowen/gpdb,ashwinstar/gpdb,greenplum-db/gpdb,xinzweb/gpdb,adam8157/gpdb,jmcatamney/gpdb,xinzweb/gpdb,50wu/gpdb,lisakowen/gpdb,50wu/gpdb,50wu/gpdb,xinzweb/gpdb,greenplum-db/gpdb,lisakowen/gpdb,xinzweb/gpdb,greenplum-db/gpdb,greenplum-db/gpdb,ashwinstar/gpdb,lisakowen/gpdb,xinzweb/gpdb,ashwinstar/gpdb,50wu/gpdb,greenplum-db/gpdb,adam8157/gpdb,jmcatamney/gpdb