Re: Lazy xid assignment V4 - Mailing list pgsql-patches

From Tom Lane
Subject Re: Lazy xid assignment V4
Date
Msg-id 28579.1188964189@sss.pgh.pa.us
Whole thread Raw
In response to Lazy xid assignment V4  ("Florian G. Pflug" <fgp@phlo.org>)
Responses Re: Lazy xid assignment V4  ("Florian G. Pflug" <fgp@phlo.org>)
List pgsql-patches
"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

pgsql-patches by date:

Previous
From: Gregory Stark
Date:
Subject: Re: HOT documentation README
Next
From: Kris Jurka
Date:
Subject: GSS warnings