On 11/13/22 01:21, Peter Eisentraut wrote:
> On 11.11.22 23:28, Jacob Champion wrote:
>> Put another way, why do we loop around and poll for more data when we
>> hit the end of the connection buffer, if we've already checked at this
>> point that we should have the entire message buffered locally?
>
> Isn't that the same behavior for other message types? I don't see
> anything in the handling of the early 'E' and 'R' messages that would
> handle this.
I agree for the 'E' case. For 'R', I see the msgLength being passed down
to pg_fe_sendauth().
> If we want to address this, maybe this should be handled
> in the polling loop before we pass off the input buffer to the
> per-message-type handlers.
I thought it was supposed to be handled by this code:
> /*
> * Can't process if message body isn't all here yet.
> */
> msgLength -= 4;
> avail = conn->inEnd - conn->inCursor;
> if (avail < msgLength)
> {
> /*
> * Before returning, try to enlarge the input buffer if
> * needed to hold the whole message; see notes in
> * pqParseInput3.
> */
> if (pqCheckInBufferSpace(conn->inCursor + (size_t) msgLength,
> conn))
> goto error_return;
> /* We'll come back when there is more data */
> return PGRES_POLLING_READING;
> }
But after this block, we still treat EOF as if we need to get more data.
If we know that the message was supposed to be fully buffered, can we
just avoid the return to the pooling loop altogether and error out
whenever we see EOF?
Thanks,
--Jacob