From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
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 19:43:26 |
Message-ID: | 22519.1235763806@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | andreas | 2009-02-28 11:03:13 | BUG #4684: lastval in function |
Previous Message | Tom Lane | 2009-02-27 18:49:44 | Re: BUG #4682: Control-\ segfaults psql |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2009-02-27 20:17:36 | Re: Synchronous replication & Hot standby patches |
Previous Message | Tom Lane | 2009-02-27 18:25:51 | Index correlation versus multi-column indexes |