Re: orangutan seizes up during isolation-check

On Fri, Oct 10, 2014 at 09:14:38PM -0400, Peter Eisentraut wrote:
> On 10/10/14 8:24 PM, Noah Misch wrote:
> > Here's an implementation thereof covering both backend and frontend use of
> > setlocale(). A setlocale() wrapper, pg_setlocale(), injects use of the child
> > process where necessary.
>
> Would such a change not be better in gnulib itself?

Good question. It would be nice to make the change there, for the benefit of
other consumers. The patch's setlocale_native_forked() assumes it never runs
in a multithreaded process, but libintl_setlocale() must not assume that. I
see a few ways libintl/gnulib might proceed:

1) exec() a helper program to run CFLocaleCopyCurrent(). Distributing that
executable alongside libintl and locating it at runtime is daunting.

2) Audit the CFLocaleCopyCurrent() code to see if it will, in practice, run
reliably in a fork of a multithreaded process. (That conclusion could
change without notice.) Use the setlocale_native_forked() technique.

3) Don't change libintl_setlocale(), but add a libintl_setlocale_nothread()
for single-threaded consumers to adopt. Each consumer will need to modify
code. libintl has a lean API; I expect adding this would be controversial.

Among those, I would probably adopt (2). We know much about the process
conditions in which pg_setlocale() will run, so placing the workaround in
PostgreSQL erases the problem of (2). I'm inclined to stick with placing the
workaround in PostgreSQL, but there are fair arguments on both sides.