Re: Unexpected "shared memory block is still in use"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Unexpected "shared memory block is still in use"
Date: 2019-05-09 21:59:39
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

I wrote:
> Noah Misch <noah(at)leadboat(dot)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

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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2019-05-09 22:32:52 Re: _bt_split(), and the risk of OOM before its critical section
Previous Message Thomas Munro 2019-05-09 21:52:57 Re: pg12 release notes