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

Re: Process local hint bit cache

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Merlin Moncure <mmoncure(at)gmail(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Process local hint bit cache
Date: 2011-04-02 19:40:23
Message-ID: 29136.1301773223@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
> On Wed, Mar 30, 2011 at 2:35 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>> btw I haven't forgotten your idea to move TransactionIdInProgress
>> Down. I think this is a good idea, and will experiment with it pre and
>> post cache.

The reason it's done in that order is to avoid race conditions.  If you
change the order you will get wrong behavior if the other transaction
ends between the TransactionIdDidCommit and the TransactionIdInProgress
tests.  I suppose you could recheck TransactionIdDidCommit a second
time, but that hardly seems likely to result in performance gains.

> aside:
> Moving TransactionIdInProgress below TransactionIdDidCommit can help
> in once sense: TransactionIdDidCommit grabs the XidStatus but discards
> the knowledge if the transaction is known aborted.

Doesn't the single-entry cache help with that?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: emanovDate: 2011-04-02 19:47:12
Subject: PG 9.0.3. How to select rows from xml
Previous:From: Tom LaneDate: 2011-04-02 19:12:32
Subject: Re: 9.0.3 SIGFAULT on FreeBSD with dtrace

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