Gregory Stark <stark@enterprisedb.com> writes:
> "Tom Lane" <tgl@sss.pgh.pa.us> writes:
>> If you issue BEGIN, then SELECT, then sit, you'll be publishing an xmin
>> but not an xid, so at that point you become a problem for VACUUM.
>> However, internally you don't have any live snapshots (if you're in READ
>> COMMITTED mode), so eventually we could have you stop publishing an xmin
>> too. That's something for 8.4 though.
> Aren't there some things that depend on the idea that even READ COMMITTED
> transactions still have a serializable snapshot lying around for them to use?
I don't see why. A READ COMMITTED transaction that is between
statements does still have a serializable snapshot sitting around, but
it won't ever reference it again. (AFAIR you can't switch an active
transaction into serializable mode.) So with a bit of work on snapshot
management we could recognize that we have no live snapshots and clear
the published xmin. This has been discussed before, eg this thread:
http://archives.postgresql.org/pgsql-patches/2007-03/msg00381.php
> This is actually one of the rough spots in HOT that I'm afraid you'll have
> problems with when you review it. If there were any HOT chains which are
> broken according to a new index definition then a any transaction considering
> using that index needs to know whether there's any possibility the plan will
> be used with a snapshot which can see those old tuples. It currently does this
> by checking if the transaction which created the index is in its serializable
> snapshot.
This seems to be a proxy for "what's the oldest live snapshot in this
backend", which is exactly what we'd have to track to adjust xmin
anyway.
regards, tom lane