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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to