Re: orangutan seizes up during isolation-check

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.