Re: Buildfarm failure analysis: penguin on 7.4 branch

must be early in the morning. I agree with removing penguin from the 7.4 branch. I have removed it on my end. Please
delete it from the database

---------- Original Message -----------
From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: jim(at)contactbda(dot)com
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, jim(at)buttafuoco(dot)net, pgsql-hackers(at)postgresql(dot)org
Sent: Mon, 18 Jul 2005 09:38:56 -0400
Subject: Re: [HACKERS] Buildfarm failure analysis: penguin on 7.4 branch

> Jim,
>
> There seems to be some confusion. The error Tom remarked on 7.4 is an
> initdb failure during the core check tests, not a tsearch2 failure,
> which is why I think he recommends discontinuing to build that branch on
> this machine.
>
> Regarding the tsearch2 failure on the 8.0 branch, I am ambivalent about
> your proposed change, to say the least. Tom made a comment some time ago
> about not hiding errors/limitations, and I agree with him. This is in a
> different class from the geometry tests, where the differences were
> largely cosmetic. I don't want people to have to read the fine print to
> see what tests were excluded - if we show a machine as green it should
> mean that machine passed the whole test suite.
>
> cheers
>
> andrew
>
> Jim Buttafuoco wrote:
>
> >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 -------
> >
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
> >
> >
> >
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
------- End of Original Message -------