The buildfarm member penguin (Debian, ARM) has been building the HEAD
branch for the most part happily since late January, but keeps failing
on the REL8_0_STABLE branch on tsearch2. It appears that some changes
made around 24-27 January fixed it for this architecture/OS. Looking in
the committers log, I see:


improve support of agglutinative languages (query with compound words)


and


Change
typedef struct {} WordEntryPos;
to
typedef uint16 WordEntryPos


Could one of these inadvertantly fix the problem we are seeing here? Do we need to backpatch to fix REL8_0_STABLE, or apply some other fix?


cheers

andrew







---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> The buildfarm member penguin (Debian, ARM) has been building the HEAD
> branch for the most part happily since late January, but keeps failing
> on the REL8_0_STABLE branch on tsearch2. It appears that some changes
> made around 24-27 January fixed it for this architecture/OS. Looking in
> the committers log, I see:
> ...
> Could one of these inadvertantly fix the problem we are seeing here?
> Do we need to backpatch to fix REL8_0_STABLE, or apply some other fix?

Nothing inadvertent about it. The changelog entry is

2005-01-25 07:36 teodor

* contrib/tsearch2/: query.c, rank.c, ts_stat.c, tsvector.c,
tsvector.h, tsvector_op.c: Change typedef struct {} WordEntryPos;
to typedef uint16 WordEntryPos according to
http://www.pgsql.ru/db/mw/msg.html?mid=2035188

Require re-fill all tsvector fields and reindex tsvector indexes.

and if you check the referenced message, the change was made
specifically to deal with this portability issue. However, we cannot
backpatch the change without forcing initdb (or at least reindex of
tsearch2 indexes), even on architectures that are not currently broken.
So I'm afraid penguin is out of luck --- the 8.0 branch has to stay
the way it is.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org

Tom Lane wrote:

> However, we cannot
>backpatch the change without forcing initdb (or at least reindex of
>tsearch2 indexes), even on architectures that are not currently broken.
>So I'm afraid penguin is out of luck --- the 8.0 branch has to stay
>the way it is.
>
>
>
>

With that exception, we now have only one machine marked active that has
consistently failed on HEAD or REL8_0_STABLE: osprey (NetBSD 2.0 gcc
3.3.3 m68k)

I have asked its owner to look into what the problems might be.

I am about to start publishing owner email addresses (in a hard to
harvest way) so that hackers can contact them directly about problems
seen on their machines. This was raised about a week ago and nobody has
raised an objection.

cheers

andrew


---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

On Sun, 26 Jun 2005, Andrew Dunstan wrote:

>
> The buildfarm member penguin (Debian, ARM) has been building the HEAD branch
> for the most part happily since late January, but keeps failing on the
> REL8_0_STABLE branch on tsearch2. It appears that some changes made around
> 24-27 January fixed it for this architecture/OS. Looking in the committers
> log, I see:
>
>
> improve support of agglutinative languages (query with compound words)
>
>
> and
>
>
> Change
> typedef struct {} WordEntryPos;
> to
> typedef uint16 WordEntryPos
>
>
> Could one of these inadvertantly fix the problem we are seeing here? Do we

NO, at least last change is incompatible with STABLE

> need to backpatch to fix REL8_0_STABLE, or apply some other fix?
>

some other fix.

>
> cheers
>
> andrew
>
>
>
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Andrew Dunstan <andrew@dunslane.net> writes:
> With that exception, we now have only one machine marked active that has
> consistently failed on HEAD or REL8_0_STABLE: osprey (NetBSD 2.0 gcc
> 3.3.3 m68k)

> I have asked its owner to look into what the problems might be.

The failure on HEAD appears to be a configuration problem (SHMMAX too
small or some such). I'm not sure why the 8.0 branch doesn't fail
likewise (maybe HEAD's shmem request is just over the boundary?).
The contrib failure in 8.0 is something we had decided not to try to
fix, IIRC, given that tsearch is going away anyway.

Is it worth trying to fix things so that the buildfarm skips tests that
are known to fail and not deemed worth fixing?

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)