Re: Intermittent stats test failures on buildfarm - Mailing list pgsql-hackers
From | Rocco Altier |
---|---|
Subject | Re: Intermittent stats test failures on buildfarm |
Date | |
Msg-id | 6E0907A94904D94B99D7F387E08C4F57443984@FALCON.INSIGHT Whole thread Raw |
In response to | Intermittent stats test failures on buildfarm (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: Intermittent stats test failures on buildfarm
|
List | 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? -rocco > -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Tom Lane > Sent: Tuesday, August 30, 2005 12:31 AM > To: pgsql-hackers@postgreSQL.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: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=ferret&dt=20 > 05-05-29%2018:25:09 > This is seen in both Check and InstallCheck steps. A variant > pathology > is seen here: > http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=gerbil&dt=20 > 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? > http://www.postgresql.org/docs/faq
pgsql-hackers by date: