"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
