invalid string enlargment PG 7.4.5 ( SOLVED )

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

I don't see the last post about the issue I had
and that was solved ( due I think to last days problems),
I post it here again:

================================================================

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
|
|
|
|> do you have any idea on what could be the reason ?
|
|
|
| I'm betting on a communications failure. What I see there is a few
| bytes of corrupted data received from the client (ie, a ridiculous
| message-length word) followed by abrupt disconnect *by the client*.
|
| You have any logs indicating what might have happened at the client
| end?

After further investigation, I discover a Servlet ( that was there running
since six months ) that was not implementing the SingleThreadModel.

Basically more instances of the same servlet were using the same
DB connection without be aware of the others. This was causing the second
servlet performing a query on an already closed communication with the server!

The question are:

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

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

iD8DBQFBOk4p7UpzwH2SGd4RAogLAKD94bNTV5PPfhKcxvdCKBolObzFJgCg8bSL
LqQS9b1H8grYNBcGKxErc28=
=n1S4
-----END PGP SIGNATURE-----

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

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