On Thu, Oct 24, 2013 at 1:13 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Stephen Frost <sfr...@snowman.net> writes: >> * Robert Haas (robertmh...@gmail.com) wrote: >>> On Wed, Oct 23, 2013 at 11:35 AM, Stephen Frost <sfr...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
