Re: Lazy xid assignment V4

"Florian G. Pflug" <fgp@phlo.org> writes:
> Here is an updated patch, following the discussion.
> The patch can be found at: http://soc.phlo.org/lazyxidassign.v4.patch

I've been working through this, and found a couple items that seem like
judgment calls:

* Is there a good reason for formatting VXIDs as %d/%X rather than
%d/%u?  There are no other columns in pg_locks that we use hex for,
so this seems a bit jarring.

* What is the rationale for keeping the transaction column in pg_locks?
The useful uniqueness/join column will be virtualtransaction.  I don't
see a very strong backwards-compatibility argument for keeping it,
because any code that depends on it being there probably thinks it's a
unique key, which it cannot be anymore.

One could actually make an argument to rename the virtualtransaction
column as transaction.  This will avoid breaking client code that thinks
that the transaction column is a unique key and isn't too wedded to the
assumption that the contents look like an integer.  If it is so wedded,
it's most likely busted anyway by the possibility that the column is
null...

Comments?

            regards, tom lane