On 16.11.22 19:35, Jacob Champion wrote:
On Tue, Nov 15, 2022 at 2:19 AM Peter Eisentraut
wrote:
I think for the current code, the following would be an appropriate
adjustment:
diff --git a/src/interfaces/libpq/fe-connect.c
b/src/interfaces/libpq/fe-connect.c
index 746e9b4f1efc..d15fb96572d9
On Tue, Nov 15, 2022 at 2:19 AM Peter Eisentraut
wrote:
> I think for the current code, the following would be an appropriate
> adjustment:
>
> diff --git a/src/interfaces/libpq/fe-connect.c
> b/src/interfaces/libpq/fe-connect.c
> index 746e9b4f1efc..d15fb96572d9 100644
> ---
On 14.11.22 19:11, Jacob Champion wrote:
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
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?
On 11.11.22 23:28, Jacob Champion wrote:
Consider the case where the server sends a
NegotiateProtocolVersion with a reasonable length, but then runs over
its own message (either by sending an unterminated string as one of the
extension names, or by sending a huge extension number). When I test
On 11/11/22 07:13, Peter Eisentraut wrote:
> On 09.11.22 00:08, Jacob Champion wrote:
>> 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
>
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
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,
On 02.11.22 20:02, Jacob Champion wrote:
A few notes:
+ else if (beresp == 'v')
+ {
+ if
(pqGetNegotiateProtocolVersion3(conn))
+ {
+
A few notes:
> + else if (beresp == 'v')
> + {
> + if
> (pqGetNegotiateProtocolVersion3(conn))
> + {
> + /* We'll come back
On 13.10.22 23:00, Nathan Bossart wrote:
On Thu, Oct 13, 2022 at 10:33:01AM +0200, Peter Eisentraut wrote:
+ if (their_version != conn->pversion)
Shouldn't this be 'their_version < conn->pversion'? If the server supports
a later protocol than what is requested but not all the requested
On Thu, Oct 13, 2022 at 10:33:01AM +0200, Peter Eisentraut wrote:
> + if (their_version != conn->pversion)
Shouldn't this be 'their_version < conn->pversion'? If the server supports
a later protocol than what is requested but not all the requested protocol
extensions, I think libpq would
We have the NegotiateProtocolVersion protocol message [0], but libpq
doesn't actually handle it.
Say I increase the protocol number in libpq:
- conn->pversion = PG_PROTOCOL(3, 0);
+ conn->pversion = PG_PROTOCOL(3, 1);
Then I get
psql: error: connection to server on socket
13 matches
Mail list logo
