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

Re: [PATCH] Lazy xid assingment V2

From: Gregory Stark <stark(at)enterprisedb(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>, "Postgresql-Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Lazy xid assingment V2
Date: 2007-08-31 23:55:47
Message-ID: 87lkbr45to.fsf@oxford.xeocode.com (view raw or flat)
Thread:
Lists: pgsql-hackers
"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> "Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
>> Tom Lane wrote:
>>> I don't much like this, since as I mentioned before I don't think
>>> MyProc->xmin is going to be constant over a whole transaction for
>>> long.  I don't think xid_age is performance-critical in any way,
>>> so I'd vote for letting it force XID assignment.
>
>> Hm... I agree that xid_age is probably not performance-critical.
>> I guess it's more the complete counter-intuitivity of forcing
>> xid assignment in some arbitrary function thats bugging me a bit.
>
> Well, I don't see it as arbitrary --- we're trying to hide the fact that
> XIDs are assigned lazily from user-visible behavior.

It seems both this and some of the other cases of having to call
ReadNewTransactionId would be eliminated if we invented a new xid treated
similarly to current_time() and others which are calculated once per
transaction and then cached for subsequent accesses. So xid_age() would
measure relative to a fixed xid, it just wouldn't be *our* xid necessarily.

Just a thought.

-- 
  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Gregory StarkDate: 2007-09-01 00:23:59
Subject: Re: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely
Previous:From: Tom LaneDate: 2007-08-31 23:35:30
Subject: pgsql: Apply a band-aid fix for the problem that 8.2 and up completely

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