"Ibrar Ahmed" <[EMAIL PROTECTED]> writes:
> 1 - export LANG=ko_KR.UTF-8
Hmph ... I can reproduce that on Fedora 9. It seems the problem is
that that translation is full of characters that don't exist in EUC-JP;
in particular the translations of both "ERROR" and "PANIC" contain
untranslatable characters. This means that every time we go to send
a message to the client, we get a recursive error trap.
The "ERRORDATA_STACK_SIZE exceeded" message is intentionally not exposed
to gettext translation, in hopes of stopping this problem, but that
doesn't help much when the PANIC message is exposed :-(.
So one thing we might try to do about it is to intentionally not allow
translation of PANIC (at line 2446 of elog.c). However, that only gets
us down from a stack-overflow crash to a PANIC, which is just about as
bad from a reliability standpoint.
I think the only permanent solution to this class of problem is going
to be something like this:
* When we hit the stack depth overflow PANIC situation in elog.c,
disable gettext so that the error will always be reported in ASCII.
* Reduce the PANIC to a FATAL so that misconfiguration of this sort
just kills the one session and doesn't cause a database crash.
This is still not very nice because what the user would get is
a complaint about ERRORDATA_STACK_SIZE exceeded with no hint that
he's got an encoding problem. It'd be better if we could get the
disable-gettext-and-FATAL-out behavior to apply to the "character
has no equivalent" error message, but I'm not sure how we do that
without bollixing up less-critical occurrences of that message.
Thoughts?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
