Skip site navigation (1) Skip section navigation (2)

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 (view raw or flat)
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

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2007-09-01 02:51:30
Subject: Re: [PATCH] Lazy xid assingment V2
Previous:From: Tom LaneDate: 2007-09-01 02:33:01
Subject: Re: [PATCH] Lazy xid assingment V2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group