loose ends in lazy-XID-assigment patch

I've committed Florian's patch, but there remain a couple of things
that need work:

* Should CSV-mode logging include the virtual transaction ID (VXID) in
addition to, or instead of, XID? There will be many situations where
there is no XID.

* As things stand, when a two-phase transaction is prepared, it drops
its lock on the original VXID; this seems necessary for reasons
previously discussed. I made the code put an invalid VXID into the
gxact structure for the prepared xact, which means that pg_locks shows
things like this:

regression=# select * from pg_locks;
locktype | database | relation | page | tuple | virtualxid | transactionid | classid | objid | objsubid | virtualtransaction | pid | mode | granted
---------------+----------+----------+------+-------+------------+---------------+---------+-------+----------+--------------------+-------+-----------------+---------
transactionid | | | | | | 21774 | | | | -1/0 | | ExclusiveLock | t
relation | 126093 | 126124 | | | | | | | | -1/0 | | AccessShareLock | t
relation | 126093 | 10969 | | | | | | | | 1/260 | 20592 | AccessShareLock | t
virtualxid | | | | | 1/260 | | | | | 1/260 | 20592 | ExclusiveLock | t
(4 rows)

This seems fairly undesirable :-( not least because you can't tell one
prepared xact from another and thus can't see which locks belong to
each. But I'm unsure what to do about it. We could have the prepared
xact continue to display the original VXID, but there would be no
certainty about the VXID remaining unique, which seems bad. Another
possibility is to put back the transaction ID column, but since that's
not unique for read-only transactions, we still don't have anything
usable as a join key.

The best idea I can think of is to make the virtualtransaction column
read out the VXID for regular transactions and the transaction ID for
prepared transactions, or maybe the transaction ID for any transaction
that has one and VXID just for read-only xacts. We can get away with
that because the column is only text and not any better-defined
datatype. It seems mighty ugly though; and changing the ID shown for
a transaction mid-stream isn't very pleasant either.

Anyone have a better idea?

regards, tom lane