Re: ERRORDATA_STACK_SIZE exceeded (server crash)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Ibrar Ahmed" <ibrar(dot)ahmad(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: ERRORDATA_STACK_SIZE exceeded (server crash)
Date: 2008-10-27 15:05:24
Message-ID: 16618.1225119924@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Ibrar Ahmed" <ibrar(dot)ahmad(at)gmail(dot)com> 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim Keitt 2008-10-27 15:17:31 Re: SPI cursor functions
Previous Message Kevin Grittner 2008-10-27 15:03:06 Re: Making pg_standby compression-friendly