Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests
Date
Msg-id CA+TgmoZV3pDkhLEUmo+1ubTWVKv=61maHTtWf0u4J+PGcQGMjw@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests  (Noah Misch <noah@leadboat.com>)
Responses Re: [HACKERS] intermittent failures in Cygwin from select_parallel tests  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On Wed, Aug 2, 2017 at 11:47 PM, Noah Misch <noah@leadboat.com> wrote:
> postmaster algorithms rely on the PG_SETMASK() calls preventing that.  Without
> such protection, duplicate bgworkers are an understandable result.  I caught
> several other assertions; the PMChildFlags failure is another case of
> duplicate postmaster children:
>
>       6 TRAP: FailedAssertion("!(entry->trans == ((void *)0))", File: "pgstat.c", Line: 871)
>       3 TRAP: FailedAssertion("!(PMSignalState->PMChildFlags[slot] == 1)", File: "pmsignal.c", Line: 229)
>      20 TRAP: FailedAssertion("!(RefCountErrors == 0)", File: "bufmgr.c", Line: 2523)
>      21 TRAP: FailedAssertion("!(vmq->mq_sender == ((void *)0))", File: "shm_mq.c", Line: 221)
>      Also, got a few "select() failed in postmaster: Bad address"
>
> I suspect a Cygwin signals bug.  I'll try to distill a self-contained test
> case for the Cygwin hackers.  The lack of failures on buildfarm member brolga
> argues that older Cygwin is not affected.

Nice detective work.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] reload-through-the-top-parent switch the partition table
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] Macros bundling RELKIND_* conditions