Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Log crashed backend's query (activity string)

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Log crashed backend's query (activity string)
Date: 2011-09-09 09:51:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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 MasaoDate: 2011-09-09 09:56:09
Subject: unite recovery.conf and postgresql.conf
Previous:From: Peter EisentrautDate: 2011-09-09 09:43:07
Subject: Re: Patch to improve reliability of postgresql on linux nfs

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group