Re: Lazy xid assignment V4

On Wednesday 05 September 2007 12:56, Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> > However, none of these are very strong reasons - certainly weaker than
> > doing what ensures to cause the least confusion. I'm therefore
> > starting to think that we should remove transaction, and keep the name
> > virtualtransaction for the VXID. That will ensure that clients who
> > *do* rely on pg_locks and the "transaction" column (which will be few,
> > I guess) at least fail early and visibly, instead of producing bogus
> > results...
>

Reading the docs, it says "Every transaction holds an exclusive lock on its
virtual transaction ID for its entire duration. If a permanent ID is assigned
to the transaction (which normally happens only if the transaction changes
the state of the database), it also holds an exclusive lock on its permanent
transaction ID until it ends."

ISTM that by removing the transaction column, there is no way to see the XID
for relations thats have been updated (which by definition will have locks on
them). Am I mis-reading the docs, or have we lost that functionality?

--
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL