Re: [WIP PATCH] Lazily assign xids for toplevel Transactions
От | Tom Lane |
---|---|
Тема | Re: [WIP PATCH] Lazily assign xids for toplevel Transactions |
Дата | |
Msg-id | 5877.1188087520@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [WIP PATCH] Lazily assign xids for toplevel Transactions ("Florian G. Pflug" <fgp@phlo.org>) |
Ответы |
Re: [WIP PATCH] Lazily assign xids for toplevel Transactions
|
Список | pgsql-hackers |
"Florian G. Pflug" <fgp@phlo.org> writes: > Tom Lane wrote: >> [ squint... ] Why do you need that? > I invented the TemporaryTransactionId because it seemed worthwhile to > distinguish between backends which do not currently run a transaction > (xid == InvalidTransactionId), and such which run a transaction that > doesn't yet have an xid assiged (xid == TemporaryTransactionId). Not really. I argue that the important distinction is between backends that have active snapshots, and those that do not. That is signaled by the value of MyProc->xmin. The startup state where the backend is starting a transaction but has not yet computed its serializable snapshot is not really particularly interesting --- indeed, where along there would you say that it has "started" its transaction, and why? The distinction you are making here is quite arbitrary. I also really dislike the idea of a backend changing its XID midstream; that essentially kills any ability of other xacts to recognize whether the backend is in the "same" transaction as it was the last time they looked. Maybe that isn't critical, but it seems like a bad ability to give up. >> If you do think it's important to distinguish the other guy's current >> and next transaction (which maybe it is), then possibly we could lock a >> combination of the PID and a *local*, per-backend transaction counter >> (there should be plenty of room in LOCKTAG for this). This counter >> value would have to be advertised in PGPROC, but there wouldn't be any >> contention involved to assign a new value. > I wanted some (single) value that would fit into some standard C datatype. Why? The only place where we need this (AFAICS) is in LOCKTAGs, and those are structs already. > Yeah - I do not really like that dual-locking thing either. But it makes > prepared transaction handling much easier - if we were to only lock the > RID, we'd have to store the rid<->xid mapping for prepared transactions Hmmm .... that's a good point. Not sure how to include prepared xacts in the scheme. regards, tom lane
В списке pgsql-hackers по дате отправления: