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

Re: Going for "all green" buildfarm results

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Going for "all green" buildfarm results
Date: 2006-07-31 21:03:35
Message-ID: 13755.1154379815@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Maybe we could write a suitable test case using Martijn's concurrent
> testing framework.

The trick is to get process A to commit between the times that process B
looks at the new and old versions of the pg_class row (and it has to
happen to do so in that order ... although that's not a bad bet given
the way btree handles equal keys).

I think the reason we've not tracked this down before is that that's a
pretty small window.  You could force the problem by stopping process B
with a debugger breakpoint and then letting A do its thing, but short of
something like that you'll never reproduce it with high probability.

As far as Andrew's question goes: I have no doubt that this race
condition is (or now, was) real and could explain Stefan's failure.
It's not impossible that there's some other problem in there, though.
If so we will still see the problem from time to time on HEAD, and
know that we have more work to do.  But I don't think that continuing
to see it on the back branches will teach us anything.

			regards, tom lane 

In response to

Responses

pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2006-07-31 21:06:20
Subject: Re: Postgres Process in Kernel Mode?
Previous:From: Michael FuhrDate: 2006-07-31 20:44:56
Subject: Re: [HACKERS] 8.2 features?

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