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

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@sss.pgh.pa.us>
To: jim@buttafuoco.net
Cc: Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.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 -------