Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Noah Misch <noah@leadboat.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2019-05-10T14:55:41Z
Lists: pgsql-hackers 
Noah Misch <noah@leadboat.com> writes:
> Looks good.  That is basically a defect in commit c09850992; the race passed
> from irrelevance to relevance when that commit subjected more segments to the
> test.  Thanks for diagnosing it.

The bug's far older than that, surely, since before c09850992 we treated
*any* shmat failure as meaning we'd better fail.  I think you're right
that c09850992 might've made it slightly more probable, but most likely
the bottom line here is just that we haven't been doing parallel
check-worlds a lot until relatively recently.  The buildfarm would be
kind of unlikely to hit this I think --- AFAIK it doesn't launch multiple
postmasters using the same port number concurrently.  But parallel
invocation of TAP test scripts makes the hazard real.

Will go fix/backpatch in a minute.

			regards, tom lane

Commits

  1. Use data directory inode number, not port, to select SysV resource keys.

  2. Cope with EINVAL and EIDRM shmat() failures in PGSharedMemoryAttach.

  3. Consistently test for in-use shared memory.