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

Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost <sfrost(at)snowman(dot)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?

regards, tom lane