Re: Sigh, my old HPUX box is totally broken by DSM patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Sigh, my old HPUX box is totally broken by DSM patch
Date: 2013-10-23 15:13:33
Message-ID: 28587.1382541213@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> I'm going to guess this idea is a non-starter, but any hope there's some
> other system call which would tell us we're on a platform where
> shm_open() will hit us with SIGSYS? What happens when shm_unlink() is
> called on this platform? Or mmap()?

For context's sake, the machine does have mmap(). shm_open and shm_unlink
exist in libc and have declarations in <sys/mman.h>, but at least the
former traps with a signal, suggesting the kernel hasn't got support for
it.

I agree with Robert that it's odd and obnoxious that the call doesn't just
return with errno = ENOSYS. However, looking in the archives turns up
this interesting historical info:
http://www.postgresql.org/message-id/25564.962066659@sss.pgh.pa.us

I wonder whether, if we went back to blocking SIGSYS, we could expect that
affected calls would return ENOSYS (clearly preferable), or if that would
just lead to some very strange behavior. Other archive entries mention
that you get SIGSYS on Cygwin if the Cygwin support daemon isn't running,
so that's at least one place where we'd want to check the behavior.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2013-10-23 15:35:32 Re: Sigh, my old HPUX box is totally broken by DSM patch
Previous Message Stephen Frost 2013-10-23 15:02:26 Re: Sigh, my old HPUX box is totally broken by DSM patch