After a system crash on a RH 7.2 box (2.4.7-10 kernel), I found that
Postgres would not restart, complaining that it	"found a pre-existing
shared memory block (ID so-and-so) still in use."

This is coming from code that attempts to defend against the scenario
where the postmaster crashed but one or more backends are still alive.
If we start a new postmaster and create a new shmem segment, the
consequences will be absolutely disastrous, because the old and new
backends will be modifying the same data files with no coordination.
So we look to see if the old shmem segment (whose ID is recorded in
the data directory lockfile) is still present and if so whether there
are any processes attached to it.  See SharedMemoryIsInUse() in
src/backend/storage/ipc/ipc.c.

The problem is that SharedMemoryIsInUse() expects shmctl to return
errno == EINVAL if the presented shmem segment ID is invalid.  What
Linux 2.4.7 is actually returning is EIDRM (identifier removed).

The easy "fix" of taking EIDRM to be an allowable return code scares
me.  At least on HPUX, the documented implication of this return code
is that the shmem segment is marked for deletion but is not yet gone
because there are still processes attached to it.  That would be
exactly the scenario after a postmaster crash and manual "ipcrm" if
there were any old backends still alive.  So, it seems to me that
accepting EIDRM would defeat the entire point of this test, at least
on some platforms.

Comments?  Is 2.4.7 simply broken and returning the wrong errno?
If not, what should we do?

			regards, tom lane

Thu, 03 Jan 2002 20:47:53 -0500
Tom Lane <tgl@sss.pgh.pa.us>
shmctl portability problem
Tom Lane wrote:
> Comments?  Is 2.4.7 simply broken and returning the wrong errno?
> If not, what should we do?

You will most surely experiment memory management (Virtual Memory) problems with
any Linux Kernel v. 2.4.x with x<15 or so. Try again using 2.4.15 or higher.

Regards,
Haroldo.

Fri, 04 Jan 2002 00:05:46 -0300
Haroldo Stenger <hstenger@adinet.com.uy>
Re: shmctl portability problem
> The easy "fix" of taking EIDRM to be an allowable return code scares
> me.  At least on HPUX, the documented implication of this return code
> is that the shmem segment is marked for deletion but is not yet gone
> because there are still processes attached to it.  That would be
> exactly the scenario after a postmaster crash and manual "ipcrm" if
> there were any old backends still alive.  So, it seems to me that
> accepting EIDRM would defeat the entire point of this test, at least
> on some platforms.
> 
> Comments?  Is 2.4.7 simply broken and returning the wrong errno?
> If not, what should we do?

Seems we have to contact linux kernel guys or dig into the kernel
ourselves to see why that is being returned.  I do have EIDRM in BSD/OS.

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 3 Jan 2002 23:59:42 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: shmctl portability problem