On 1/1/15 11:04 PM, Noah Misch wrote: >> Clusters hosted on OS X fall into these categories: >> >> 1) Unaffected configuration. This includes everyone setting a valid messages >> locale via LANG, LC_ALL or LC_MESSAGES. >> 2) Affected configuration. Through luck and light use, the cluster would not >> experience the crashes/hangs. >> 3) Cluster would experience the crashes/hangs. >> >> DBAs in (3) want the FATAL at startup, but those in (2) want a LOG message >> instead. DBAs in (1) don't care. Since intermittent postmaster hangs are >> far >> worse than startup failure, if (2) and (3) have similar population, FATAL is >> the better bet. If (2) is sufficiently more populous than (3), then the many >> small pricks from startup failure do add up to hurt more than the occasional >> postmaster hang. Who knows how that calculation plays out. > > The first attached patch, for all branches, adds LOG-level messages and an > assertion. So cassert builds will fail hard, while others won't. The second > patch, for master only, changes the startup-time message to FATAL. If we > decide to use FATAL in all branches, I would just squash them into one.
What I'm seeing now is that the unaccent regression tests when run under make check-world abort with FATAL: postmaster became multithreaded during startup HINT: Set the LC_ALL environment variable to a valid locale. My locale settings for this purpose are LANG="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_CTYPE="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_ALL= The environment variable LANG is set, all the other ones are not set. I could presumably set LC_ALL, but then I lose the ability to set different locales for different categories. Running LC_ALL=$LANG make -C contrib/unaccent check doesn't fix it; I get the same error. The behavior is also a bit strange. The step ============== starting postmaster ============== hangs for one minute before failing. This probably has nothing to do with your change, but maybe pg_regress could detect postmaster startup failures better. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
