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.