Buildfarm failure analysis: penguin on 7.4 branch

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
Subject: Buildfarm failure analysis: penguin on 7.4 branch
Date: 2005-07-18 05:05:09
Message-ID: 24947.1121663109@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2005-07-18 07:28:00 Re: Missing info for buildfarm reports
Previous Message Tom Lane 2005-07-18 04:35:46 Missing info for buildfarm reports