Re: Going for "all green" buildfarm results

From: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, 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-08-17 13:09:03
Message-ID: 44E46A6F.7090603@kaltenbrunner.cc
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
>> maybe the following buildfarm report means that we need a new theory :-(
>
>> http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=sponge&dt=2006-08-16%2021:30:02
>
> Vacuum's always had a race condition: it makes a list of rel OIDs and
> then tries to vacuum each one. It narrows the window for failure by
> doing a SearchSysCacheExists test before relation_open, but there's
> still a window for failure.
>
> The rel in question is most likely a temp rel of another backend,
> because sanity_check is running by itself and so there shouldn't
> be anything else happening except perhaps some other session's
> post-disconnect cleanup. Maybe we could put the check for "is
> this a temp rel of another relation" into the initial list-making
> step instead of waiting till after relation_open. That doesn't
> seem to solve the general problem though.

hmm yeah - missed the VACUUM; part of the regression diff.
Still this means we will have to live with (rare) failures once in a
while during that test ?

Stefan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Volkan YAZICI 2006-08-17 13:13:25 Re: "cache reference leak" and "problem in alloc set" warnings
Previous Message Tom Lane 2006-08-17 13:02:36 Re: Going for "all green" buildfarm results