"could not reattach to shared memory" on buildfarm member dory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: "could not reattach to shared memory" on buildfarm member dory
Date: 2018-04-23 21:10:20
Message-ID: 25495.1524517820@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

So far, dory has failed three times with essentially identical symptoms:

2018-04-23 19:57:10.624 GMT [2240] FATAL: could not reattach to shared memory (key=0000000000000190, addr=00000000018E0000): error code 487
2018-04-23 15:57:10.657 EDT [8836] ERROR: lost connection to parallel worker
2018-04-23 15:57:10.657 EDT [8836] STATEMENT: select count(*) from tenk1 group by twenty;
2018-04-23 15:57:10.660 EDT [3820] LOG: background worker "parallel worker" (PID 2240) exited with exit code 1

Now how can this be? We've successfully reserved and released the address
range we want to use, so it *should* be free at the instant we try to map.

Another thing that seems curious, though it may just be an artifact of
not having many data points yet, is that these failures all occurred
during pg_upgradecheck. You'd think the "check" and "install-check"
steps would be equally vulnerable to the failure.

I guess the good news is that we're seeing this in a reasonably
reproducible fashion, so there's some hope of digging down to find
out the actual cause.

regards, tom lane

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2018-04-23 21:10:24 Re: Should we add GUCs to allow partition pruning to be disabled?
Previous Message Andres Freund 2018-04-23 20:14:48 Re: PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS