"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? 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. It seems weird to have the planner using snapshots in any way, but I don't see any direct problems which arise. Essentially it's using the serializable snapshot as a proxy for better live snapshot bookkeeping. If there's no serializable snapshot then any future snapshot taken will surely not be able to see the old tuples, and if there is then it should be fine (though not as good as possible if we did more bookkeeping) to use it to determine whether the old tuples could possibly be visible when the plan is executed. I'm a bit afraid the plan will stay cached longer than would be ideal. If the plan doesn't use the new index then ideally we would want to invalidate it from the cache at the end of this transaction I suppose. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org
