Re: orangutan seizes up during isolation-check

On Wed, Dec 31, 2014 at 01:52:49PM -0500, Noah Misch wrote:
> On Sun, Dec 28, 2014 at 07:20:04PM -0500, Andrew Dunstan wrote:
> > On 12/28/2014 04:58 PM, Noah Misch wrote:
> > >The gettext maintainer was open to implementing the setlocale_native_forked()
> > >technique in gettext, though the last visible progress was in October.  In any
> > >event, PostgreSQL builds will see older gettext for several years.  If
> > >setlocale-darwin-fork-v1.patch is not wanted, I suggest making the postmaster
> > >check during startup whether it has become multithreaded.  If multithreaded:
> > >
> > >   FATAL: postmaster became multithreaded during startup
> > >   HINT: Set the LC_ALL environment variable to a valid locale.
>
> > >I would like to go ahead and commit setlocale-main-harden-v1.patch, which is a
> > >good thing to have regardless of what happens with gettext.
> > >
> >
> > I'm OK with this, but on its own it won't fix orangutan's problems, will it?
>
> Right; setlocale-main-harden-v1.patch fixes a bug not affecting orangutan at
> all.  None of the above will make orangutan turn green.  Checking
> multithreading during startup would merely let it fail cleanly.

OS X --enable-nls buildfarm members should run tests under LANG=C instead of
with locale environment variables unset (make check NO_LOCALE=1).  I see two
ways to arrange that: (1) add a build-farm.conf option, or (2) have
pg_regress.c:initialize_environment() treat OS X like Windows.  I mildly favor
(2); see attached, untested patch.  Windows and OS X --enable-nls share the
characteristic that setlocale(LC_x, "") consults sources other than
environment variables.  (I do wonder why commit 4a6fd46 used LANG=en instead
of LANG=C.)  On the other hand, LANG=en has been inessential on Windows ever
since "pg_regress --no-locale" started to use "initdb --no-locale".  While I
prefer to see the LANG= hack go away rather than proliferate, I can't cite a
practical reason to care.

Thanks,
nm