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
---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at
http://www.postgresql.org/about/donate
