ERRORDATA_STACK_SIZE panic crashes on Windows
От | Tom Lane |
---|---|
Тема | ERRORDATA_STACK_SIZE panic crashes on Windows |
Дата | |
Msg-id | 8077.1211142757@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: ERRORDATA_STACK_SIZE panic crashes on Windows
|
Список | 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
В списке pgsql-hackers по дате отправления: