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-09-05T00:25:22Z
Lists: pgsql-hackers

Attachments

I wrote:
> This still isn't committable as-is, since the test will just curl up
> and die on machines lacking IPC::SharedMem.

After a bit of research, here's a version that takes a stab at fixing
that.  There may be cleaner ways to do it, but this successfully skips
the test if it can't import the needed IPC modules.

This also fixes a problem that the previous script had with leaking
a shmem segment.  That's due to something that could be considered
a pre-existing bug, which is that if we use shmem key X+1, and the
postmaster crashes, and the next start is able to get shmem key X,
we don't clean up the shmem segment at X+1.  In principle, we could
note from the contents of postmaster.pid that X+1 was used before and
try to remove it.  In practice, I doubt this is worth worrying about
given how small the shmem segments are now, and the very low probability
of key collisions in the new regime.  Anyway it would be material for
a different patch.

I think this could be considered committable, but if anyone wants to
improve the test script, step right up.

			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.