Re: ERRORDATA_STACK_SIZE panic crashes on Windows

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

In response to

Responses

Browse pgsql-hackers by date

  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