From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: "could not adopt C locale" failure at startup on Windows |
Date: | 2015-06-18 14:31:55 |
Message-ID: | 3561.1434637915@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Noah Misch <noah(at)leadboat(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2015-06-18 15:12:26 | Re: s_lock() seems too aggressive for machines with many sockets |
Previous Message | Heikki Linnakangas | 2015-06-18 13:55:18 | Re: pg_rewind failure by file deletion in source server |