Re: libpq support for NegotiateProtocolVersion
От | Jacob Champion |
---|---|
Тема | Re: libpq support for NegotiateProtocolVersion |
Дата | |
Msg-id | 608d9d2f-f102-9266-8802-57188a552a78@timescale.com обсуждение исходный текст |
Ответ на | Re: libpq support for NegotiateProtocolVersion (Peter Eisentraut <peter.eisentraut@enterprisedb.com>) |
Ответы |
Re: libpq support for NegotiateProtocolVersion
|
Список | pgsql-hackers |
A few notes: > + else if (beresp == 'v') > + { > + if (pqGetNegotiateProtocolVersion3(conn)) > + { > + /* We'll come back when there is more data */ > + return PGRES_POLLING_READING; > + } > + /* OK, we read the message; mark data consumed */ > + conn->inStart = conn->inCursor; > + goto error_return; > + } This new code path doesn't go through the message length checks that are done for the 'R' and 'E' cases, and pqGetNegotiateProtocolVersion3() doesn't take the message length to know where to stop anyway, so a misbehaving server can chew up client resources. It looks like the server is expecting to be able to continue the conversation with a newer client after sending a NegotiateProtocolVersion. Is an actual negotiation planned for the future? I think the documentation on NegotiateProtocolVersion (not introduced in this patch) is misleading/wrong; it says that the version number sent back is the "newest minor protocol version supported by the server for the major protocol version requested by the client" which doesn't seem to match the actual usage seen here. Thanks, --Jacob
В списке pgsql-hackers по дате отправления: