Re: [PATCH] Lazy xid assingment V2

From: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgresql-Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Lazy xid assingment V2
Date: 2007-09-01 02:50:53
Message-ID: 46D8D38D.4080206@phlo.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> Actually, after more thought on this I'd
>> argue that the only really correct reference for computing a xid's
>> age is GetOldestXmin(). It's what VACUUM uses to calculate the
>> freezeLimit, after all. Now, using GetOldestXmin() directly is probably
>> unwise because it might change at any time. So I now think that
>> using RecentOldestXmin is the correct thing to do. The fact that it
>> might change between statements for a read-committed transaction
>> is quite natural I'd say.
>
> It might change between statements for a serializable transaction too;
> or within statements for either kind, because it depends on the actions
> of other xacts not just our own. That doesn't seem like a good plan at
> all.
>
> If you wanted to cache GetOldestXmin()'s result on first use of xid_age
> within a transaction, then okay, but is it worth that much trouble?

D'oh - I managed to add confusion here I think, by writing RecentOldestXmin
(which just doesn't exist ;-) where I meant RecentGlobalXmin (which does
exist). RecentGlobalXmin is updated whenever we set a new snapshot.
(And nowhere else, I believe).

> Another perspective on this is that ReadNewTransactionId is the correct
> reference point for xid_age, because what you really want to know about
> when you use it is how much daylight there is before xid wraparound.
> So maybe we should redefine xid_age as a volatile function that indeed
> uses ReadNewTransactionId on every call. But that is probably going to
> complicate use of the function more than is justified.
I can see your point there. With that perspective in mind, using the
current snapshot's xmax might be an option. That would be the best
approximation of ReadNewTransactionId() that still allows
xid_age to be STABLE.

> I note that pg_description defines xid_age as "age of a transaction ID,
> in transactions before current transaction", and I'm content to stick
> with that definition. Even if it does force consuming an XID. I'm not
> sure that we could devise a comparably succinct description of any of
> these other proposed behaviors, nor that we should even consider
> changing that description.
If we use LatestSnapshot->xmax, we could write "age of a transaction ID,
in transactions before (the) start of (the) current transaction".

greetings, Florian Pflug

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-09-01 02:51:30 Re: [PATCH] Lazy xid assingment V2
Previous Message Tom Lane 2007-09-01 02:33:01 Re: [PATCH] Lazy xid assingment V2