Re: Sigh, my old HPUX box is totally broken by DSM patch
От | Tom Lane |
---|---|
Тема | Re: Sigh, my old HPUX box is totally broken by DSM patch |
Дата | |
Msg-id | 28587.1382541213@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Sigh, my old HPUX box is totally broken by DSM patch (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Sigh, my old HPUX box is totally broken by DSM patch
|
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.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
В списке pgsql-hackers по дате отправления: