From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
Cc: | Marti Raudsepp <marti(at)juffo(dot)org>, 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-08 00:22:30 |
Message-ID: | CA+TgmoZ0BAZe_3_b+h0LC=WTU9VYwJX0qAiL0tNz6Y9H7v74gQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Sep 7, 2011 at 5:24 PM, Alvaro Herrera
<alvherre(at)commandprompt(dot)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 <alvherre(at)commandprompt(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-09-08 00:22:44 | Moving core timestamp typedefs/macros somewhere else |
Previous Message | Tom Lane | 2011-09-07 23:39:15 | Re: FATAL: lock AccessShareLock on object 0/1260/0 is already held |