On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: > Excerpts from Marti Raudsepp's message of mié sep 07 18:09:32 -0300 2011: >> On Wed, Sep 7, 2011 at 22:42, Alvaro Herrera <alvhe...@commandprompt.com> >> wrote: >> > A mishandled encoding conversion could be problematic, so that needs to >> > be carefully considered (perhaps just shut off unconditionally). >> >> Are you referring to log file encoding or something else? The log file >> is already potentially mixed-encoding, as different databases may have >> different encodings and backends just dump bytes to it in their >> current encoding. > > I am referring to the fact that whatever the backend puts in shared > memory is going to be in its encoding setting, which may not necessarily > match the postmaster's. And if it doesn't, the postmaster might try to > convert it using settings not valid for the string, possibly leading to > crashes. > > I remember we had bugs whereby an encoding conversion would fail, > leading to elog trying to report this problem, but this attempt would > also incur a conversion step, failing recursively until elog's stack got > full. I'm not saying this is impossible to solve, just something to > keep in mind.
Can we do something like: pass through ASCII characters unchanged, and output anything with the high-bit set as \x<hexdigit><hexdigit>? That might be garbled in some cases, but the goal here is not perfection. We're just trying to give the admin (or PostgreSQL-guru-for-hire) a clue where to start looking for the problem. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers