Re: loose ends in lazy-XID-assigment patch - Mailing list pgsql-hackers

Tom Lane wrote:
> 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.
Maybe make %x show both, or only the xid if that is set, and the vxid
otherwise? That would probably be what most existing users of %x want.
For those who want them seperated, we'd have %v (vxid), and maybe
%X (xid only). Seems a bit like overkills, though...

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

We could make the VXID in the gxact struct be
backendId=InvalidBackendId, lxid=xid. That'd be still an invalid vxid, but not
the same for every prepared transaction.

If we take this further, we could get rid of the lock on the xid completely,
I believe. We'd define some PermanentBackendId (lets say, -2, since -1 is
taken). When preparing the xact, we'd drop the lock on the old VXID, and
instead acquire one on (PermanentBackendId, xid). Waiting on an xid would
become a bit tricky, but doable I think. We'd have to first check the procarray
- if we find the xid there, we translate it to a vxid, and wait on that.
Aftwards (whether we found a vxid, or not) we wait on (PermanentBackendId, xid).
That doesn't exactly make XactLockTableWait cheaper, but that might be OK,
since we

I haven't really thought this through, though. I think that with carefull
ordering of things we can control the race conditions this might posses -
but I'm not sure at this point.

greetings, Florian Pflug