Noah Misch 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
>>
On Wed, Jun 17, 2015 at 01:43:55PM -0400, Tom Lane wrote:
> Noah Misch writes:
> > On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
> >> It's mere chance that the order of calls to pg_perm_setlocale() is
> >> such that the code works now; and it's not hard to imagine future
> >> changes i
Noah Misch writes:
> On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
>> It's mere chance that the order of calls to pg_perm_setlocale() is
>> such that the code works now; and it's not hard to imagine future
>> changes in gettext, or reordering of our own code, that would break it.
> pg
On Mon, Jun 15, 2015 at 12:37:43PM -0400, Tom Lane wrote:
> After further thought, ISTM that this bug is evidence that 5f538ad
> was badly designed, and the proposed fix has blinkers on. If
> pg_bind_textdomain_codeset() is looking at the locale environment,
> we should not be calling it from insi
On Mon, Jun 15, 2015 at 08:47:12AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > While Windows was the bellwether, harm potential is greater on non-Windows
> > systems. pg_perm_setlocale() sets the LC_CTYPE environment variable to help
> > PL/Perl avoid clobbering the process locale; see plperl
Noah Misch writes:
> A faster test is to set LC_CTYPE=C in the environment and run "postgres
> --version". The root cause is a bug my commit 5f538ad introduced at the start
> of the 9.4 cycle. pg_perm_setlocale() now calls pg_bind_textdomain_codeset(),
> which calls setlocale(LC_CTYPE, NULL). P
Noah Misch writes:
> On Wed, Jun 10, 2015 at 10:09:38AM -0400, Tom Lane wrote:
>> Hm. I could understand getting encoding difficulties in that environment,
>> but it's hard to see why they'd manifest like this. Can you trace through
>> pg_perm_setlocale and figure out why it's reporting failure?
On Wed, Jun 10, 2015 at 10:09:38AM -0400, Tom Lane wrote:
> Noah Misch writes:
> > I can reproduce this with "initdb --locale=C",
> > postgresql-9.4.3-1-windows-binaries.zip (32-bit), Windows 7 x64, and the
> > Windows ANSI code page set to CP936. (Choose "Chinese (Simplified, PRC)" in
> > Contro
Noah Misch writes:
> On Tue, Jun 09, 2015 at 12:24:02PM -0400, Tom Lane wrote:
>> Yeah, my first instinct was to blame ca325941 as well, but I don't think
>> any of that code executes during init_locale(). Also,
>> http://www.postgresql.org/message-id/20150326040321.2492.24...@wrigleys.postgresql
On Tue, Jun 09, 2015 at 12:24:02PM -0400, Tom Lane wrote:
> Andres Freund writes:
> > The error seems odd. The only even remotely related change between 9.4.1
> > and .2 seems to be ca325941. Could also be a build environment change.
>
> Yeah, my first instinct was to blame ca325941 as well, but
Andres Freund writes:
> On 2015-06-09 11:20:06 -0400, Tom Lane wrote:
>> We've seen several reports of $SUBJECT lately. I have no idea what's
>> going on, but it occurred to me that it could be informative to tweak
>> init_locale() so that it reports which category failed to be set.
>> Any object
On 2015-06-09 11:20:06 -0400, Tom Lane wrote:
> We've seen several reports of $SUBJECT lately. I have no idea what's
> going on, but it occurred to me that it could be informative to tweak
> init_locale() so that it reports which category failed to be set.
> Any objections to squeezing that into t
We've seen several reports of $SUBJECT lately. I have no idea what's
going on, but it occurred to me that it could be informative to tweak
init_locale() so that it reports which category failed to be set.
Any objections to squeezing that into today's releases?
regards, tom
13 matches
Mail list logo
