From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: Heath Lord <heath.lord@crunchydata.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Stephen Frost <sfrost@snowman.net>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: "could not reattach to shared memory" on buildfarm member dory
Date: Mon, 30 Apr 2018 23:33:32 -0400
Message-ID: <15345.1525145612@sss.pgh.pa.us> (raw)
In-Reply-To: <20180501025914.GA2777381@rfd.leadboat.com>
References: <25495.1524517820@sss.pgh.pa.us>
<20180423231855.GK27724@tamriel.snowman.net>
<CAEepm=0kRF7Hrd2R72FJLdQneV1HATjJM_ArbjZw=-ZF3RT7+Q@mail.gmail.com>
<20180424070646.GA2693533@rfd.leadboat.com>
<17897.1525108069@sss.pgh.pa.us>
<29823.1525132900@sss.pgh.pa.us>
<20180501025914.GA2777381@rfd.leadboat.com>
Noah Misch <noah@leadboat.com> writes:
> On Mon, Apr 30, 2018 at 08:01:40PM -0400, Tom Lane wrote:
>> What seems like a plausible theory at this point is that the apparent
>> asynchronicity is due to the allocation being triggered by a different
>> thread, and the fact that our added monitoring code seems to make the
>> failure more likely can be explained by that code changing the timing.
>> But what thread could it be? It doesn't really look to me like either
>> the signal thread or the timer thread could eat 4MB. syslogger.c
>> also spawns a thread, on Windows, but AFAICS that's not being used in
>> this test configuration.
The 1-second wait doesn't seem to have changed things much, which puts
a hole in the idea that this is triggered by a thread spawned earlier
in backend process startup.
>> Maybe the reason dory is showing the problem
>> is something or other is spawning a thread we don't even know about?
> Likely some privileged daemon is creating a thread in every new process.
Yeah, I'm afraid that's the most likely theory at this point; it offers
an explanation why we're seeing this on dory and not other machines.
Although if the daemon were responding to process startup, wouldn't the
extra wait have given it time to do so? There's still something that
doesn't add up here.
>> Any other ideas?
> PostgreSQL could retry the whole process creation, analogous to
> internal_forkexec() retries.
In the absence of any clearer theory about what's causing this,
that may be our only recourse. Sure is ugly though.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: tgl@sss.pgh.pa.us, noah@leadboat.com, heath.lord@crunchydata.com, thomas.munro@enterprisedb.com, sfrost@snowman.net, pgsql-hackers@lists.postgresql.org
Subject: Re: "could not reattach to shared memory" on buildfarm member dory
In-Reply-To: <15345.1525145612@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox