Re: Sigh, my old HPUX box is totally broken by DSM patch
От | Robert Haas |
---|---|
Тема | Re: Sigh, my old HPUX box is totally broken by DSM patch |
Дата | |
Msg-id | CA+TgmobDRxssayoviPvxDy=iS9nUaAvRKW9MO7sbvMR205srOg@mail.gmail.com обсуждение исходный текст |
Ответ на | 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 |
On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost <sfrost@snowman.net> wrote: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: >> 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 > > Wow, well, good on HPUX for trying to run the code you told it to.. > >> 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. > > Would this make sense as a configure-time check, rather than initdb, to > try blocking SIGSYS and checking for an ENOSYS from shm_open()? Seems > preferrable to do that in a configure check rather than initdb. I don't see why. It's a run-time behavior; the build system may not be where the binaries will ultimately run. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: