Tom Lane wrote:
I wrote:
Yeah. The intent of the protocol design was that the recipient could
skip over the correct number of bytes even if it didn't have room to
buffer them, but the memory allocation mechanism in the backend makes
it difficult to actually do that. Now that we have PG_TRY, thoug
I wrote:
> Yeah. The intent of the protocol design was that the recipient could
> skip over the correct number of bytes even if it didn't have room to
> buffer them, but the memory allocation mechanism in the backend makes
> it difficult to actually do that. Now that we have PG_TRY, though,
> it
Oliver Jowett <[EMAIL PROTECTED]> writes:
> What appears to be happening is that the backend goes into error
> recovery as soon as the allocation fails (just after reading the message
> length), and never does the read() of the body of the Bind message. So
> it falls out of sync, and tries to in
(Tom: this is not as severe a problem as I first thought)
If a client sends a V3 message that is sufficiently large to cause a
memory allocation failure on the backend when allocating space to read
the message, the backend gets out of sync with the protocol stream.
For example, sending this:
FE
