Re: Low hanging fruit in lazy-XID-assignment patch?

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)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?

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