Re: invalid string enlargment PG 7.4.5 ( SOLVED ) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: invalid string enlargment PG 7.4.5 ( SOLVED )
Date
Msg-id 17396.1094345661@sss.pgh.pa.us
Whole thread Raw
In response to invalid string enlargment PG 7.4.5 ( SOLVED )  (Gaetano Mendola <mendola@bigfoot.com>)
Responses Re: invalid string enlargment PG 7.4.5 ( SOLVED )  (Gaetano Mendola <mendola@bigfoot.com>)
List pgsql-hackers
Gaetano Mendola <mendola@bigfoot.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


pgsql-hackers by date:

Previous
From: "Marc G. Fournier"
Date:
Subject: Re: APR 1.0 released
Next
From: Christopher Kings-Lynne
Date:
Subject: Re: Adding columns in the middle of tables