Re: invalid string enlargment PG 7.4.5 ( SOLVED )

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gaetano Mendola <mendola(at)bigfoot(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: invalid string enlargment PG 7.4.5 ( SOLVED )
Date: 2004-09-05 00:54:21
Message-ID: 17396.1094345661@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gaetano Mendola <mendola(at)bigfoot(dot)com> writes:
> |> ERROR: invalid string enlargement request size 1476395004
> |> DEBUG: AbortCurrentTransaction
> |> WARNING: AbortTransaction and not in in-progress state
> |> ERROR: could not send data to client: Broken pipe
> |> PANIC: error during error recovery, giving up

> ~ - why with the 7.4.2 I never notice it ( I know a critical race could be
> ~ there for years and pop-ut in any moment ) ?
> ~ - why for a not well client behaviour the server go in PANIC ?

It's not supposed to. I was able to reproduce this in 7.4 by arranging
for the client disconnect to occur at just the right time (it has to
happen *after* the 'invalid string enlargement' message is sent to the
client, but *before* the 'not in in-progress' message gets sent, so that
that latter message is the first one to get a send failure).

I cannot duplicate the problem in 8.0 but I'm unconvinced that it
couldn't happen. I think what we should do about it is rejigger
errstart() so that COMMERROR isn't promoted up to ERROR just because
it happens during error recovery. Really the notion of promoting
errors is wrongheaded to start with --- if it's a below-ERROR case
then we should just print it and return.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2004-09-05 03:06:41 Re: Adding columns in the middle of tables
Previous Message Marc G. Fournier 2004-09-05 00:06:38 Re: APR 1.0 released