Tom Lane wrote:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.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