Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions
Date
Msg-id 22519.1235763806@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #4680: Server crashed if using wrong (mismatch) conversion functions  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List pgsql-bugs
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 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.

Well, your proposed patch replaces core dump due to stack overflow with
core dump due to abort(), which is no improvement at all as far as
avoiding a DOS situation goes.  The only way we could really improve
matters on that scale would be if we were willing to consider this a
non-PANIC situation, which is a bit scary.  Though I suppose that if the
error originally being reported weren't a PANIC, there is no reason
we shouldn't try to convert the scenario to a plain FATAL exit.

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.

            regards, tom lane

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #4682: Control-\ segfaults psql
Next
From: "andreas"
Date:
Subject: BUG #4684: lastval in function