Re: "could not adopt C locale" failure at startup on Windows - Mailing list pgsql-hackers

From Tom Lane
Subject Re: "could not adopt C locale" failure at startup on Windows
Date
Msg-id 3561.1434637915@sss.pgh.pa.us
Whole thread Raw
In response to Re: "could not adopt C locale" failure at startup on Windows  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
Noah Misch <noah@leadboat.com> writes:
> On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote:
>> I'm not exactly sure that they wouldn't be garbled anyway during the
>> interval where we're setting these things up.  Until DatabaseEncoding,
>> ClientEncoding, and gettext's internal notions are all in sync, we
>> are at risk of that type of issue no matter what.

> True; the window exists and is small enough both ways.  This is merely one
> more reason to fix the bug without fixing what ain't broke.

[ shrug... ]  I'm not planning to waste a whole lot more breath on this
topic, but to my mind the current definition of pg_perm_setlocale() *is*
broke.  Previously, that function only interacted with the standard libc
locale facilities.  Now it's also entangled with gettext(), as well as
SetMessageEncoding and GetDatabaseEncoding.  IMO that extra cross-module
entanglement is the exact reason we have a bug here.  It's a layering
violation and I think we should get rid of it.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pg_rewind failure by file deletion in source server
Next
From: Robert Haas
Date:
Subject: Re: s_lock() seems too aggressive for machines with many sockets