Re: Lazy xid assignment V4

Tom Lane wrote:
> "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.

The reason was the desire not to bloat the string length unnecessarily.
Since the first part is now %d anyways, it only really saves 2 bytes, though...

> * 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...

Wouldn't code that assumes that transaction is "not null" be broken already,
because of session locks?

I left it there because they only way to get it back if we remove it is to
join pg_locks on itself. Thats quite a lot of work - both in terms of typing
and CPU cycles to just get that one column.

I felt that if we remove the holder's xid from pg_locks, we ought to add it
pg_stat_activity, probably along with the virtual transaction id. I actually
wanted to do this, but then didn't because currently pg_stat_activity is rather
tightly bound to the stats collector. Adding random other values seemes like a
bit of a hack...

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...

If we go ahead, and rename virtualtransaction to transaction, I think we should
at least put some non-numeric character in front of the virtualtransaction.
Most language's string-to-integer functions will happily convert
"<number><string>" to the integer <number>. So if they indeed treat
virtualtransaction as something int-like, they'd silently use only the backendId
instead of the full VXID.

greetings, Florian Pflug