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"
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>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 09 May 2019 09:47:34 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2225.1557439179.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 09 May 2019 17:59:39 -0400
Message-ID: <2226.1557439179@sss.pgh.pa.us>
Precedence: bulk

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 =3D=3D 0.  Previously, if a shmem segment had zero at=
tach
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