Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction

2007-07-23 Thread Tom Lane
Sibte Abbas [EMAIL PROTECTED] writes: I think printing the first 1K would make more sense. If I understand you correctly, the code path which you are referring to is the send_message_to_server_log() function in elog.c? No, the place that has to change is where errstart() detects that we're

Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction

2007-07-23 Thread Sibte Abbas
On 7/23/07, Tom Lane [EMAIL PROTECTED] wrote: No, the place that has to change is where errstart() detects that we're recursing. We could possibly have it first try to make a shorter string and only give up entirely if recursion happens again, but given that this is such a corner case I don't

Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction

2007-07-21 Thread Chris Hoover
On 7/20/07, Tom Lane [EMAIL PROTECTED] wrote: I guess what we need to do is hack the emergency-recovery path for error-during-error-processing such that it will prevent trying to print a very long debug_query_string. Maybe we should just not try to print the command at all in this case, or

Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction

2007-07-21 Thread Sibte Abbas
On 7/20/07, Tom Lane [EMAIL PROTECTED] wrote: I guess what we need to do is hack the emergency-recovery path for error-during-error-processing such that it will prevent trying to print a very long debug_query_string. Maybe we should just not try to print the command at all in this case, or

Re: [HACKERS] [GENERAL] 8.2.4 signal 11 with large transaction

2007-07-20 Thread Tom Lane
Bill Moran [EMAIL PROTECTED] writes: Oddly, the query succeeds if it's fed into psql. I'm now full of mystery and wonder. It would appear as if the underlying problem has something to do with PHP, but why should this cause a backend process to crash? Ah, I see it. Your PHP script is