Oliver Jowett <oliver@opencloud.com> 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 interpret the guts of the Bind as a
> new message. Bad server, no biscuit.
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 might not be out of reach to do it right. Something like
PG_TRY(); buf = palloc(N);PG_CATCH(); read and discard N bytes; re-raise the out-of-memory
error;PG_END_TRY();normalread path
I'm not sure how many places would need to be touched to make this
actually happen; if memory serves, the "read a packet" code extends
over multiple logical levels.
regards, tom lane
