Gregory Stark <[EMAIL PROTECTED]> writes: > "Tom Lane" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
