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

Tom Lane wrote:
> I wrote:
>> In any case, that's orthogonal to the part that I was focusing on,
>> which was to try to prevent error recursion as a result of trouble
>> in the encoding conversion subsystem.  It looks like we could do that
>> with some additional hacking in send_message_to_frontend() to avoid
>> conversion, as well as translation, when in_error_recursion_trouble()
>> is true.  Your point about there possibly being non-ASCII user-inserted
>> data in the message is a bit troubling, but for the cases where
>> recursion is actually occurring I don't think that that will happen.
> 
> Here is a proposed patch that does this.  It largely reverts my patch
> of 2008-10-27 in favor of a more general policy that says that *all*
> localization of error messages is disabled once we get into error
> recursion trouble.  Having done that, we can reasonably assume that
> the error message text is 7-bit ASCII, and therefore bypass encoding
> conversion as well.  This fixes the example reported in bug #4680
> (even without the subsequent patch to prevent that case from arising),
> and it still prevents the cases that my previous patch was meant to
> deal with.
> 
> Comments, objections?

Looks ok to me. I'm still a bit uneasy about the assumption that the 
error message is 7-bit ACII. Maybe that's just because I don't fully 
understand all the conditions how we can end up in recursion, so I would 
still put something into pq_send_raw_string to check that the string 
really is 7-bit ASCII. Just in case. Maybe clear all the high bits, or 
replace non-ASCII characters with question marks.

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