Stephen Frost <> writes:
> * Robert Haas ( wrote:
>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost <> 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
*** 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);
+   /* 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,
  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.


                        regards, tom lane

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to