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

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Denis Afonin <vadm(at)itkm(dot)ru>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions
Date: 2009-02-27 12:14:34
Message-ID: 49A7D92A.7080808@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-bugs pgsql-hackers

Denis Afonin wrote:
> test=# CREATE DEFAULT CONVERSION test1 FOR 'LATIN1' TO 'KOI8' FROM
> ascii_to_mic;
> CREATE CONVERSION
> test=# CREATE DEFAULT CONVERSION test2 FOR 'KOI8' TO 'LATIN1' FROM
> mic_to_ascii;
> CREATE CONVERSION
> test=# set client_encoding to 'LATIN1';
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> Соединение с сервером было потеряно.
> Попытка переустановить: Безуспешно.

Hmm, this seems to be another variant of the recursive error issue fixed
earlier:
http://archives.postgresql.org/message-id/20081027193722.283B67545A4@cvs.postgresql.org

Only this time the problem the error doesn't occur in translation, but
in encoding conversion. We could doo something similar to what we did
before with the translation, and try not to call conversion function in
case of a recursive error. However, sending an error message to the
client in wrong encoding is not as sane as sending it untranslated.

I think we should instead try to break the PANIC cycle. If we exceed
ERRORDATA_STACK_SIZE, and we're already PANICing, we should just die
immediately instead of throwing another PANIC about exceeding the stack
size. The attached patch does that.

However, a more serious issue is that a regular user can do that and
bring down the whole system. I suggest that we make "CREATE [DEFAULT]
CONVERSION" to call the conversion function with a empty string, to
check that it is in fact capable of doing the conversion. See 2nd
attached patch. This is a usability improvement too, as you

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

Attachment Content-Type Size
break-PANIC-cycle-1.patch text/x-diff 3.5 KB
check-conversion-func-compatibility-1.patch text/x-diff 1.2 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Heikki Linnakangas 2009-02-27 15:10:45 Re: BUG #4679: invalid UTF-8 byte sequence detected near byte 0xa3 + postgresql
Previous Message aiwaniuk 2009-02-27 11:33:43 Re: BUG #4677: memory growth

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2009-02-27 12:19:26 Re: Immediate shutdown and system(3)
Previous Message Peter Eisentraut 2009-02-27 11:32:34 Error codes for LIMIT and OFFSET