My theory is "select;" incurs a parse error and this error message is
supposed to be translated into your encoding, but unfortunately not every
UTF8 character is necessarily be encoded as GB18030, which will cause an
infinite recursive elogs just like this:

1:elog(parse_error) // contain unencodable characters
2: elog(report_not_translatable) // contain unencodable characters
again
3: elog(report_report_not_translatable)
4: elog(report_report_report_not_translatable)
5: ...

and corrupt the elog stack.

To fix this, we could just print a "Unsupport encoding" message which is
just a plain ascii character string and stop the recursion at step 3.

Regards,
Qingqing

"Ñîçß" <yayooo (AT) gmail (DOT) com> writes


---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Has this been fixed already?

---------------------------------------------------------------------------

Qingqing Zhou wrote:
--
Bruce Momjian | http://candle.pha.pa.us
pgman (AT) candle (DOT) pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

Bruce Momjian <pgman (AT) candle (DOT) pha.pa.us> writes:
No. My suggestion of using bind_textdomain_codeset() might fix it,
but I'm not sufficiently familiar with the NLS code to want to try to
install that myself.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly