[HACKERS] 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 ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] loose ends in lazy-XID-assigment patch
Tom Lane wrote: * 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. But will there be any where we care? Isn't the point of this to restrict allocation of a real XID to situations where having one might actually matter? All the rest seems to me just bookkeeping. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] loose ends in lazy-XID-assigment patch
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
Re: [HACKERS] loose ends in lazy-XID-assigment patch
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: * 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. But will there be any where we care? Isn't the point of this to restrict allocation of a real XID to situations where having one might actually matter? All the rest seems to me just bookkeeping. Well, the point is that a transaction might well emit log messages when it hasn't changed anything and hence hasn't got an XID. If you would like to be able to match up the messages generated by a single transaction, you'd need to have VXID available to use as a join key. In any case it seems a bit odd that we have a value that's available in log_line_prefix and not available to users of CSV log output. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] loose ends in lazy-XID-assigment patch
Florian G. Pflug [EMAIL PROTECTED] writes: Tom Lane wrote: 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 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. Hmm, that would work. If we take this further, we could get rid of the lock on the xid completely, Maybe, but let's not go there for now. I was already bending the rules to push this into 8.3 --- I think further improvement needs to wait for 8.4. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
