On Fri, Sep 9, 2011 at 2:51 AM, Marti Raudsepp <marti@juffo.org> wrote:
> On Thu, Sep 8, 2011 at 03:22, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
>> <alvherre@commandprompt.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
> messages.
>
>> 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.
Should this patch be reviewed as is, or will the substitution of
non-ASCII be implemented?
It seems like everyone agrees that this feature is wanted, but Tom is
still very much opposed to the general approach to implement it, as
being too dangerous.
Is it the reviewer's job to try to convince him otherwise?
Thanks,
Jeff
