Re: [WIP PATCH] Lazily assign xids for toplevel Transactions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: [WIP PATCH] Lazily assign xids for toplevel Transactions
Date: 2007-08-26 00:18:40
Message-ID: 5877.1188087520@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Florian G. Pflug" <fgp(at)phlo(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2007-08-26 04:07:29 Re: Final background writer cleanup for 8.3
Previous Message Florian G. Pflug 2007-08-25 23:50:53 Re: [WIP PATCH] Lazily assign xids for toplevel Transactions