Re: Buildfarm failure analysis: penguin on 7.4 branch

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 -------