Re: Buildfarm failure analysis: penguin on 7.4 branch

Jim,

There seems to be some confusion. The error Tom remarked on 7.4 is an
initdb failure during the core check tests, not a tsearch2 failure,
which is why I think he recommends discontinuing to build that branch on
this machine.

Regarding the tsearch2 failure on the 8.0 branch, I am ambivalent about
your proposed change, to say the least. Tom made a comment some time ago
about not hiding errors/limitations, and I agree with him. This is in a
different class from the geometry tests, where the differences were
largely cosmetic. I don't want people to have to read the fine print to
see what tests were excluded - if we show a machine as green it should
mean that machine passed the whole test suite.

cheers

andrew

Jim Buttafuoco wrote:

>Tom,
>
>I agree with NOT fixing the tsearch2 code for this failure in 7.4. I have left penguin building 7.4 just to see if the
>core code continues to compile. I would be nice if the build farm code would let me exclude a contrib module if
>necessary. What do you think Andrew?
>
>Jim
>
>
>---------- Original Message -----------
>From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
>To: jim(at)buttafuoco(dot)net
>Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
>Sent: Mon, 18 Jul 2005 01:05:09 -0400
>Subject: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch
>
>
>
>>Buildfarm member penguin has never got past this point in half a year of
>>trying:
>>
>>creating template1 database in
>>/home/postgres/pgfarmbuild/REL7_4_STABLE/pgsql.7701/src/test/regress/./tmp_check/data/base/1... ok
>>initializing pg_shadow... TRAP: FailedAssertion("!(StrategyEvaluationIsValid(evaluation))", File: "istrat.c",
>> Line: 273)
>>
>>Unfortunately it never will :-(, and I'd recommend removing 7.4 from its
>>to-do list.
>>
>>The problem here appears to be the same unusual struct packing rules
>>that make tsearch2 fail on this machine in the 8.0 branch. The old
>>"index strategy" code assumes that given this set of struct
>>declarations:
>>
>>typedef uint16 StrategyNumber;
>>
>>typedef struct StrategyOperatorData
>>{
>> StrategyNumber strategy;
>> bits16 flags; /* scan qualification flags, see skey.h */
>>} StrategyOperatorData;
>>
>>typedef struct StrategyTermData
>>{ /* conjunctive term */
>> uint16 degree;
>> StrategyOperatorData operatorData[1]; /* VARIABLE LENGTH ARRAY */
>>} StrategyTermData; /* VARIABLE LENGTH STRUCTURE */
>>
>>the contents of StrategyTermData are equivalent to a uint16 array
>>containing {degree, strategy1, flags1, strategy2, flags2, ... }.
>>This is true on 99% of machines out there, but the compiler penguin is
>>using thinks it should align StrategyOperatorData on a word boundary,
>>and so there is padding between the "degree" and the first array
>>element.
>>
>>The compiler is within its rights to do this per the ANSI C spec, but
>>considering that we'd never seen this problem in ten years of Postgres
>>use and that the struct is gone (for unrelated reasons) in PG 8.0 and
>>up, I don't think anyone is likely to feel like messing with the 7.*
>>code to fix it.
>>
>>(This is all extrapolation, mind you, but given what we found out about
>>the problem with tsearch2, I feel reasonably confident in the analysis.)
>>
>> regards, tom lane
>>
>>---------------------------(end of broadcast)---------------------------
>>TIP 3: Have you checked our extensive FAQ?
>>
>> http://www.postgresql.org/docs/faq
>>
>>
>------- End of Original Message -------
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>
>
>