Buildfarm failure analysis: penguin on 7.4 branch - Mailing list pgsql-hackers

From Tom Lane
Subject Buildfarm failure analysis: penguin on 7.4 branch
Date
Msg-id 24947.1121663109@sss.pgh.pa.us
Whole thread Raw
Responses Re: Buildfarm failure analysis: penguin on 7.4 branch  ("Jim Buttafuoco" <jim@contactbda.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Missing info for buildfarm reports
Next
From: "Andrew Dunstan"
Date:
Subject: Re: Missing info for buildfarm reports