Re: libpq support for NegotiateProtocolVersion
От | Peter Eisentraut |
---|---|
Тема | Re: libpq support for NegotiateProtocolVersion |
Дата | |
Msg-id | a3e6b3fe-1667-8335-a5fc-d148afeb3d5d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: libpq support for NegotiateProtocolVersion (Jacob Champion <jchampion@timescale.com>) |
Ответы |
Re: libpq support for NegotiateProtocolVersion
|
Список | pgsql-hackers |
On 09.11.22 00:08, Jacob Champion wrote: > On 11/8/22 00:40, Peter Eisentraut wrote: >> On 02.11.22 20:02, Jacob Champion wrote: >>> 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. >> >> Fixed in new patch. > > pqGetNegotiateProtocolVersion3() is still ignoring the message length, > though; it won't necessarily stop at the message boundary. I don't follow. The calls to pqGetInt(), pqGets(), etc. check the message length. Do you have something else in mind? Can you give an example or existing code? >>> 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. >> >> I don't follow. If libpq sends a protocol version of 3.1, then the >> server responds by saying it supports only 3.0. What are you seeing? > > I see what you've described on my end, too. The sentence I quoted seemed > to imply that the server should respond with only the minor version (the > least significant 16 bits). I think it should probably just say "newest > protocol version" in the docs. Ok, I see the distinction.
В списке pgsql-hackers по дате отправления: