Re: invalid string enlargment PG 7.4.5 ( SOLVED )

From: Gaetano Mendola <mendola(at)bigfoot(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 10:01:19
Message-ID: 413AE3EF.3030206@bigfoot.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Lane wrote:

| 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.

mmm print and return or print and go ahead?

I don't know what you do during an error recovery but I guess that by design
nothing must go wrong during an error handler. In C++ for example is good
norm not throw an exception inside the distructors of a class this because
if a previous exception was thrown the second exception is thrown in the
middle of a stack unwinding. If an exception is thrown during the stack
unwinding the only way to don't have memory leakage is exit!

Consider this sequence during the recovery:

deallocate resource-1;
Check-1;
...
deallocate resource-n;
Check-n;

if Check-i return because an error you risk to not deallocate the following
resources.

May be I'm wrong ;-)

Regards
Gaetano Mendola

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBOuPr7UpzwH2SGd4RAqlIAJ4gq+8fWVeg+WcgeeWzA0DWZxFi1gCfYw6V
VCZ7wuDDdn6nEJw/HO+NcFU=
=+6hL
-----END PGP SIGNATURE-----

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2004-09-05 10:10:10 Re: Adding columns in the middle of tables
Previous Message Gaetano Mendola 2004-09-05 09:40:05 Re: Developers page is down