From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | ERRORDATA_STACK_SIZE panic crashes on Windows |
Date: | 2008-05-18 20:32:37 |
Message-ID: | 8077.1211142757@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
I spent some time chasing the theory that the conversion from
UTF8 to the client encoding was failing; but if that's the case
it should be reproducible on non-Windows machines, and I didn't
have any luck with that.
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. This is reinforced by the mention of changing
lc_messages in the first report above. We had had some discussions
of trying to adjust the LC_XXX values to ensure that they all
represent the same encoding choice, but I don't believe that got done.
It might also be significant that both complainants are using UTF8
database encoding; IIRC that has some weird status in the Windows
locale world.
I am also toying with the idea of disabling gettext usage once we
get past two or so levels of error nesting, in order to prevent the
recursion panic in this type of scenario --- but it would be real
nice to know for certain what is happening before we try to fix it.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Lor | 2008-05-18 20:41:14 | Re: New DTrace probes proposal |
Previous Message | Andrew Dunstan | 2008-05-18 20:09:40 | Re: notification information functions |