From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@lists.postgresql.org
Subject: Re: Unexpected "shared memory block is still in use"
Date: Thu, 09 May 2019 17:59:39 -0400
Message-ID: <2226.1557439179@sss.pgh.pa.us> (raw)
In-Reply-To: <2663.1557409654@sss.pgh.pa.us>
References: <22224.1557340366@sss.pgh.pa.us>
<20190509055414.GB1066859@rfd.leadboat.com>
<2663.1557409654@sss.pgh.pa.us>
I wrote:
> Noah Misch <noah@leadboat.com> writes:
>> The odds are very high that you would not have gotten that error before that
>> commit. But if the cause matches your guess, it's not something wrong with
>> the commit ...
> Fair point.
After more study and testing, I no longer believe my original thought
about a bootstrap-to-standalone-backend race condition. The bootstrap
process definitely kills its SysV shmem segment before exiting.
However, I have a new theory, after noticing that c09850992 moved the
check for shm_nattch == 0. Previously, if a shmem segment had zero attach
count, it was unconditionally considered not-a-threat. Now, we'll try
shmat() anyway, and if that fails for any reason other than EACCES, we say
SHMSTATE_ANALYSIS_FAILURE which leads to the described error report.
So I suspect that what we hit was a race condition whereby some other
parallel test was using the same shmem ID and we managed to see its
segment successfully in shmctl but then it was gone by the time we did
shmat. This leads me to think that EINVAL and EIDRM failures from
shmat had better be considered SHMSTATE_ENOENT not
SHMSTATE_ANALYSIS_FAILURE.
In principle this is a longstanding race condition, but I wonder
whether we made it more probable by moving the shm_nattch check.
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, pgsql-hackers@lists.postgresql.org
Subject: Re: Unexpected "shared memory block is still in use"
In-Reply-To: <2226.1557439179@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