On 12/28/2014 04:58 PM, Noah Misch wrote:
> On Sat, Oct 11, 2014 at 09:07:46AM -0400, Peter Eisentraut wrote:
>> On 10/11/14 1:41 AM, Noah Misch wrote:
>>> 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:
>> Yeah, it's difficult to see how they might proceed if they keep calling
>> into Core Foundation, which might do anything, now or in the future.
>>
>> I went ahead and submitted a bug report to gettext:
>> https://savannah.gnu.org/bugs/index.php?43404
>>
>> (They way I understand it is that the files concerned originate in
>> gettext and are copied to gnulib.)
>>
>> Let's see what they say.
> 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 wondered whether to downgrade FATAL to LOG in back branches. Introducing a
> new reason to block startup is disruptive for a minor release, but having the
> postmaster deadlock at an unpredictable later time is even more disruptive. I
> am inclined to halt startup that way in all branches.
Yeah. It should be easily fixable, AIUI, and startup is surely a good
and obvious time to to that.
>
>> I like the idea of calling pthread_is_threaded_np() as a verification.
>> This appears to be a OS X-specific function at the moment. If other
>> platforms start adding it, then we'll run into the usual problems of how
>> to link binaries that use pthread functions. Maybe that's not a
>> realistic concern.
> True. As written, "configure" will report the function unavailable if it
> requires threading libraries. For a measure that's just a backstop against
> other bugs, that may be just right.
>
>
> 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?
cheers
andrew
