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

Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Denis Afonin <vadm(at)itkm(dot)ru>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions
Date: 2009-02-27 16:57:27
Message-ID: 49A81B77.9000606@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-hackers
Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
>> Tom Lane wrote:
>>> I wonder how ugly it would be to try to suppress encoding
>>> conversion as well?
> 
>> The error message might contain user data, which might contain non-ASCII 
>> characters. Or maybe not, but it seems like a shaky assumption to make. 
> 
> The particular cases we are concerned about here will not.  In any case
> it's a better result than dying without sending any message at all,
> which would be the result of the patch you propose.

Well, you'd still have the message in the log, which is more important.

We could bypass the normal encoding conversion and sanitize the message 
from any non-ASCII characters before sending it. Or just send a 
hard-coded "we're in big trouble" message that we know to not contain 
any non-ASCII characters. But seems like a "can't happen" scenario like 
this doesn't deserve that much extra effort. And it would only handle 
conversion errors; if there's any other similar scenario involving, um, 
something else, we'll have the same problem again. We didn't envision 
this encoding issue when we fixed the translation case, mind you.

I think it would be good to have a circuit-breaker to break the infinite 
recursion in case PANIC fails and recurses, for any reason.

(I committed the other patch, BTW, to test that the conversion function 
specified in CREATE CONVERSION works)

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2009-02-27 18:25:51
Subject: Index correlation versus multi-column indexes
Previous:From: Tom LaneDate: 2009-02-27 16:37:25
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions

pgsql-bugs by date

Next:From: Josh BerkusDate: 2009-02-27 17:10:53
Subject: Re: Weird quirk with pg_dump of complex types
Previous:From: Tom LaneDate: 2009-02-27 16:37:25
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions

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