Re: [HACKERS] 8.2.4 signal 11 with large transaction

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Sibte Abbas" <sibtay(at)gmail(dot)com>
Cc: "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] 8.2.4 signal 11 with large transaction
Date: 2007-07-23 17:44:03
Message-ID: 29933.1185212643@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

"Sibte Abbas" <sibtay(at)gmail(dot)com> 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
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 think it's worth the complexity and
risk of further bugs. I've made it just drop the statement at the same
time that it decides to give up on printing other context (which can
also be a source of out-of-memory problems btw).
http://archives.postgresql.org/pgsql-committers/2007-07/msg00215.php

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robert Fitzpatrick 2007-07-23 17:58:22 Using COALESCE nside function
Previous Message Woody Woodring 2007-07-23 16:02:55 Should SERIAL column have MAXVAL set on sequence

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2007-07-23 17:54:32 Re: 8.2 is 30% better in pgbench than 8.3
Previous Message Florian G. Pflug 2007-07-23 17:36:43 Re: Full page images in WAL & Cache Invalidation