Buildfarm failure analysis: penguin on 7.4 branch

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Buildfarm failure analysis: penguin on 7.4 branch
Дата
Msg-id 24947.1121663109@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Buildfarm failure analysis: penguin on 7.4 branch  ("Jim Buttafuoco" <jim@contactbda.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Missing info for buildfarm reports
Следующее
От: "Andrew Dunstan"
Дата:
Сообщение: Re: Missing info for buildfarm reports