On Thu, Sep 8, 2011 at 03:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
> <alvherre(at)commandprompt(dot)com> wrote:
>> 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.
Looking at elog.c, this only seems to apply to messages sent to the
client from a backend connection. No conversion is done for log
> 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.
Or we might just replace them with '?'. This has the advantage of not
expanding query length 4x if it does happen to be corrupted. The vast
majority of queries are ASCII-only anyway.
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2011-09-09 09:56:09|
|Subject: unite recovery.conf and postgresql.conf|
|Previous:||From: Peter Eisentraut||Date: 2011-09-09 09:43:07|
|Subject: Re: Patch to improve reliability of postgresql on linux