Re: Sigh, my old HPUX box is totally broken by DSM patch - Mailing list pgsql-hackers

On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Robert Haas (robertmhaas@gmail.com) wrote:
>>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost <sfrost@snowman.net> wrote:
>>>> 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.
>
>> I suppose, just need to be more cautious when blocking signals in initdb
>> than in a configure-time check, of course.
>
> Indeed, telling initdb to ignore SIGSYS makes it do what we want on
> this box:
>
> $ git diff
> diff --git a/src/bin/initdb/initdb.c b/src/bin/initdb/initdb.c
> index 3983b23731330b78a66a74d14faaf76f7aff85c2..05252df869d128ac2cf3b1c48c6259d6d95b0ffc 100644
> *** a/src/bin/initdb/initdb.c
> --- b/src/bin/initdb/initdb.c
> *************** setup_signals(void)
> *** 3197,3202 ****
> --- 3197,3207 ----
>   #ifdef SIGPIPE
>     pqsignal(SIGPIPE, SIG_IGN);
>   #endif
> +
> +   /* Prevent SIGSYS so we can probe for kernel calls that might not work */
> + #ifdef SIGSYS
> +   pqsignal(SIGSYS, SIG_IGN);
> + #endif
>   }
>
>
> $ initdb
> ...
> selecting dynamic shared memory implementation ... sysv
> ...
>
> The above patch ignores SIGSYS throughout initdb.  We could narrow the
> possible side-effects by only disabling SIGSYS around the shm_open call,
> but I'm not sure there's any value in that.  It seems likely to me that
> the same kind of problem might pop up elsewhere in future, as we try
> to make use of other modern kernel facilities.  In fact, I can foresee
> wanting to run the whole backend this way --- though I'm not proposing
> doing so today.
>
> A bit of googling turned up the following paragraph of rationale in the
> POSIX spec (Open Group Base Specifications 2013 edition):
>
>   There is very little that a Conforming POSIX.1 Application can do by
>   catching, ignoring, or masking any of the signals SIGILL, SIGTRAP,
>   SIGIOT, SIGEMT, SIGBUS, SIGSEGV, SIGSYS, or SIGFPE. They will generally
>   be generated by the system only in cases of programming errors. While it
>   may be desirable for some robust code (for example, a library routine)
>   to be able to detect and recover from programming errors in other code,
>   these signals are not nearly sufficient for that purpose. One portable
>   use that does exist for these signals is that a command interpreter can
>   recognize them as the cause of termination of a process (with wait())
>   and print an appropriate message.
>
> So in other words, the reason for delivering SIGSYS rather than returning
> ENOSYS by default is to make it apparent from the process exit code that
> you made an invalid kernel call, should your code be sloppy enough that
> it fails to notice and report kernel call failures.  This argument doesn't
> seem to me to hold a lot of water for Postgres' purposes.
>
> Comments?

Your proposed change to initdb seems fine to me.

If we change initdb but not the backend, then somebody could later
manually change postgresql.conf to set
dynamic_shared_memory_type=posix.  When they try to restart the
postmaster, it'll die with SIGSYS rather than exiting with a
relatively clean error message.  However, at the moment, it seems like
the only people who are likely to encounter that situation are those
who install PostgreSQL 9.4 on very old HP-UX boxen and then change the
configuration settings chosen by initdb, and there shouldn't be many
such people.  Therefore I tend to think that changing initdb is
sufficient for now; we can take the risk of changing the backend's
handling of SIGSYS if and when it becomes clear that there's enough
benefit to doing so to justify the risk.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company