Re: invalid string enlargment PG 7.4.5 ( SOLVED )
От | Gaetano Mendola |
---|---|
Тема | Re: invalid string enlargment PG 7.4.5 ( SOLVED ) |
Дата | |
Msg-id | 413AE3EF.3030206@bigfoot.com обсуждение исходный текст |
Ответ на | Re: invalid string enlargment PG 7.4.5 ( SOLVED ) (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tom Lane wrote: | 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. 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-----
В списке pgsql-hackers по дате отправления: