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 might not be out of reach to do it right.
And indeed it wasn't. Patch committed.
Thanks!
Re your commit comment:
I'm a bit dubious that this is a real problem, since the client likely doesn't have any more space available than the server, but it's not hard to make it behave according to the protocol intention.
It's quite possible that the client isn't keeping the whole parameter in memory. For example, JDBC has a method that allows a streamable parameter (with prespecified length) to be set, and the stream contents could be coming from disk or computed on demand. That is actually where I came across the problem in the first place.
-O
---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend
