From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: ERRORDATA_STACK_SIZE panic crashes on Windows |
Date: | 2008-05-26 17:20:23 |
Message-ID: | 23227.1211822423@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Have any Windows-using hackers tried to look into the reports of
> $SUBJECT on 8.3? We have two fresh reports:
> http://archives.postgresql.org/pgsql-bugs/2008-05/msg00106.php
> http://archives.postgresql.org/pgsql-bugs/2008-05/msg00109.php
> and this isn't the first time we've heard of it.
And now we have another report:
http://archives.postgresql.org/pgsql-bugs/2008-05/msg00159.php
for which the complainant was kind enough to supply the requested
details, and they seem to confirm my previous theory:
> What I'm currently thinking is that maybe gettext() isn't on the
> same page as us concerning what encoding it's supposed to produce
> its output in.
After digging around in the source code a bit, the reason why (and why
it's only seen on Windows) became blindingly obvious :-(. On Windows
we specifically allow UTF-8 database encoding to be selected regardless
of the system locale settings. This is (AFAIK) safe for the basic
locale-dependent stuff we do, because that all goes through special
UTF-16-using code paths. But it leaves gettext utterly misinformed
about what it is supposed to do.
Fortunately there is a way to tell gettext what to do, and accordingly
I propose the attached patch. I am not in a position to test it
however. Would somebody replicate the failure and confirm this
fixes it?
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
unknown_filename | text/plain | 1.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Davis | 2008-05-26 17:23:15 | Re: Proposal: temporal extension "period" data type |
Previous Message | Hannu Krosing | 2008-05-26 16:57:00 | Re: Read Uncommitted |