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

Re: Intermittent stats test failures on buildfarm

From: "Rocco Altier" <RoccoA(at)Routescape(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <pgsql-hackers(at)postgreSQL(dot)org>
Subject: Re: Intermittent stats test failures on buildfarm
Date: 2005-08-30 19:45:39
Message-ID: 6E0907A94904D94B99D7F387E08C4F57443984@FALCON.INSIGHT (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Also, kookaburra (AIX) has a problem with the stats test as well.

What is most puzzling to me is that it only happens with cc (not gcc).
And I can only get it to happen when running a cronjob for the
buildfarm.  If I run it interactively, the stats collector will run
fine, or if I run the build script from the command line.

The environment between cron and from command line are not significantly
different, so I am at a bit of loss as to the reason why.

Any thoughts?


> -----Original Message-----
> From: pgsql-hackers-owner(at)postgresql(dot)org 
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Tom Lane
> Sent: Tuesday, August 30, 2005 12:31 AM
> To: pgsql-hackers(at)postgreSQL(dot)org
> Subject: [HACKERS] Intermittent stats test failures on buildfarm
> I just spent a tedious hour digging through the buildfarm results
> to see what I could learn about the intermittent failures we're seeing
> in the stats regression test, such as here:
> 05-05-29%2018:25:09
> This is seen in both Check and InstallCheck steps.  A variant 
> pathology
> is seen here:
> 05-07-22%2007:58:01
> Notice that only the heap stats columns are wrong in this 
> case, not the
> index stats.  I think that this variant behavior may have 
> been fixed by
> this patch:
> 2005-07-23 20:33  tgl
> 	* src/backend/postmaster/pgstat.c: Fix some failures to 
> initialize
> 	table entries induced by recent autovacuum integration. 
>  Not clear
> 	this explains recent stats problems, but it's definitely wrong.
> but it's not certain since nobody traced through the code to exhibit
> why those uninitialized table entries would have led to this 
> particular
> visible symptom.  But with no occurrences of that behavior since the
> patch went in, I suspect it's fixed.
> What we are left with turns out to be multiple occurrences of 
> the first
> pathology on exactly three buildfarm members:
> 	ferret		Cygwin
> 	kudu		Solaris 9, x86
> 	dragonfly	Solaris 9, x86
> There are no occurrences of the failure on the native-Windows 
> machines,
> nor on buzzard (Solaris 10, SPARC), nor on gerbil (Solaris 9, SPARC)
> (though gerbil has one old occurrence of the second 
> pathology, so maybe
> that observation should be taken with a grain of salt).  And none
> whatever on any other buildfarm member.
> The same three machines are showing the failure in the 8.0 
> branch, too,
> so it's not a recently-introduced issue.
> And one thing more: kudu and dragonfly are actually the same machine,
> same OS, different compilers.
> So what to make of this?  Dunno, but it is clearly a very
> platform-specific behavior.  Anyone see a connection between Cygwin
> and Solaris?
> 			regards, tom lane
> ---------------------------(end of 
> broadcast)---------------------------
> TIP 3: Have you checked our extensive FAQ?


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-08-30 20:26:50
Subject: Re: 8.1 observation
Previous:From: Tony CadutoDate: 2005-08-30 19:01:34
Subject: 8.1 observation

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