From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | 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-09-29 20:16:24 |
Message-ID: | CA+TgmobnmFzXGvNXXkmw65z882ppC-rnDAOYQZHy8T2cKzb48Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 29, 2014 at 3:37 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Yea :(. Note how signals are blocked in all the signal handlers and only
> unblocked for a very short time (the sleep).
>
> (stare at random shit for far too long)
>
> Ah. DetermineSleepTime(), which is called while signals are unblocked!,
> modifies BackgroundWorkerList. Previously that only iterated the list,
> without modifying it. That's already of quite debatable safety, but
> modifying it without having blocked signals is most definitely
> broken. The modification was introduced by 7f7485a0c...
Ouch. OK, yeah, that's a bug.
> If you can manually run stuff on that machine, it'd be rather helpful if
> you could put a PG_SETMASK(&BlockSig);...PG_SETMASK(&UnBlockSig); in the
> HaveCrashedWorker() loop.
I'd do it the other way around, and adjust ServerLoop to put the
PG_SETMASK calls right around pg_usleep() and select(). But why futz
with anole? Let's just check in the fix. It'll either fix anole or
not, but we should fix the bug you found either way.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-09-29 20:16:38 | Re: open items for 9.4 |
Previous Message | Tom Lane | 2014-09-29 20:14:54 | Re: json (b) and null fields |