loose ends in lazy-XID-assigment patch
От | Tom Lane |
---|---|
Тема | loose ends in lazy-XID-assigment patch |
Дата | |
Msg-id | 20677.1189017024@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: loose ends in lazy-XID-assigment patch
(Andrew Dunstan <andrew@dunslane.net>)
Re: loose ends in lazy-XID-assigment patch ("Florian G. Pflug" <fgp@phlo.org>) |
Список | pgsql-hackers |
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 | trelation | 126093 | 126124 | | | | | | | | -1/0 | | AccessShareLock | trelation | 126093 | 10969 | | | | | | | | 1/260 | 20592 | AccessShareLock | tvirtualxid | | | | | 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
В списке pgsql-hackers по дате отправления: