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

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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:02:26
Message-ID: 20131023150226.GK2706@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> I don't think a configure-time test is a good idea because there's no
> guarantee that the configure-time machine and the run-time machine
> have the same behavior. But having initdb fork a child process to run
> the test seems like a reasonable way forward, even though I feel like
> it shouldn't really be needed. One possibly unfortunate things is
> that SIGSYS at least on my box normally produces a core dump, so the
> initdb child might leave behind a core file somewhere as a side
> effect. Not sure if we can or want to work around that somehow.

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()?

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-10-23 15:13:33 Re: Sigh, my old HPUX box is totally broken by DSM patch
Previous Message Tom Lane 2013-10-23 14:58:09 Re: Using indexes for ORDER BY and PARTITION BY clause in windowing functions