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

Re: Curious buildfarm failures (fwd)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, pgsql-hackers(at)postgreSQL(dot)org, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: Curious buildfarm failures (fwd)
Date: 2013-01-16 01:32:00
Message-ID: 8203.1358299920@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-01-15 19:56:52 -0500, Tom Lane wrote:
>> At this point I'm more interested in his report in
>> <alpine(dot)LRH(dot)2(dot)03(dot)1301152012220(dot)773(at)ast(dot)cam(dot)ac(dot)uk> about
>> the Assert at spgdoinsert.c:1222 failing.  That's pretty new code, so
>> more likely to have a genuine bug, and I wonder if it's related to
>> the spgist issue in <50EBF992(dot)2000704(at)qunar(dot)com> ...

> Yes, it looks more like it could be something real. There are
> suspicously many other failing tests though (misc, with) that don't seem
> to be related to the spgist crash.

Looking again, the pg_regress output appears to indicate two separate
crashes (one during rangetypes, the other during create_index).  The
reported Assert trap was in the rangetypes test, but the other one
could very easily have been from spgist code as well.  I'd tend to
write off all the other reported diffs as followon damage from the
crashes, at least without clearer evidence that they weren't.  There are
very many instances in our regression tests where failure to complete
one test results in bogus diffs in later ones, because DB objects don't
exist or don't have the expected contents.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Andres FreundDate: 2013-01-16 01:34:52
Subject: Re: Curious buildfarm failures (fwd)
Previous:From: Andres FreundDate: 2013-01-16 01:13:26
Subject: Re: Curious buildfarm failures (fwd)

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