From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Christoph Berg <cb(at)df7cb(dot)de>, Andres Freund <andres(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dave Page <dave(dot)page(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, CM Team <cm(at)enterprisedb(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, bernd(dot)helmle(at)credativ(dot)de |
Subject: | Re: test_shm_mq failing on anole (was: Sending out a request for more buildfarm animals?) |
Date: | 2014-11-24 16:59:04 |
Message-ID: | CA+TgmoacnppMdgg4n14U2BjujNDNMOU8xxHhPMvO+0u92ckH+w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 24, 2014 at 9:36 AM, Christoph Berg <cb(at)df7cb(dot)de> wrote:
> I'm still seeing trouble with test_shm_mq on mipsel (9.4 rc1):
Boy, that test has certainly caught its share of bugs, and not in the
places I would have expected.
The last round of wrestling with this had to do with working around
HP-UX behavior that differs from Linux. So it seems like this is
likely to be an altogether different failure than what we saw on
anole.
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mipsel&ver=9.4~rc1-1&stamp=1416547779
>
> mips had the problem as well in the past (9.4 beta3):
>
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mips&ver=9.4~beta3-3&stamp=1413607370
> https://buildd.debian.org/status/fetch.php?pkg=postgresql-9.4&arch=mips&ver=9.4~beta3-1&stamp=1412893135
For how long did was it hung before you killed it?
> The mips beta3 failures eventually went away when the build was done
> on a different machine. This was the first time the mipsel build was
> done on this build machine, so it seems the problem might well be
> caused by some subarchitecture difference.
Does it fail every time when run on a machine where it fails sometimes?
It might not be related to the subarchitecture difference in any
particularly interesting way; it could just be a race condition that
is triggered, or not, depending on the precise timing of things, which
might vary based on subarchitecture, compiler, running kernel version,
etc.
> Anyone got an idea?
Not off-hand. :-(
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Jaime Casanova | 2014-11-24 17:24:48 | Re: Turning recovery.conf into GUCs |
Previous Message | David G Johnston | 2014-11-24 16:50:06 | Re: Turning recovery.conf into GUCs |