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