public inbox for [email protected]
help / color / mirror / Atom feed[PATCH] Correct the version sent in protocol negotiation
3+ messages / 2 participants
[nested] [flat]
* [PATCH] Correct the version sent in protocol negotiation
@ 2026-06-07 02:00 Ning Sun <[email protected]>
2026-06-07 05:06 ` Re: [PATCH] Correct the version sent in protocol negotiation Laurenz Albe <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Ning Sun @ 2026-06-07 02:00 UTC (permalink / raw)
To: [email protected]
Our protocol doc describes protocol negotiation message will send latest
minor version. However that field is a 4-byte one. The actual
implementation sends full version including the major part:
static void
SendNegotiateProtocolVersion(List *unrecognized_protocol_options)
{
StringInfoData buf;
ListCell *lc;
pq_beginmessage(&buf, PqMsg_NegotiateProtocolVersion);
pq_sendint32(&buf, FrontendProtocol);
pq_sendint32(&buf, list_length(unrecognized_protocol_options));
foreach(lc, unrecognized_protocol_options)
pq_sendstring(&buf, lfirst(lc));
pq_endmessage(&buf);
/* no need to flush, some other message will follow */
}
The patch included just clarifies this behavior by removing "minor" from
"newest minor version".
Attachments:
[text/x-patch] 0001-Protocol-negotiation-sends-full-version-instead-of-m.patch (1.5K, 2-0001-Protocol-negotiation-sends-full-version-instead-of-m.patch)
download | inline diff:
From 1bb00e792fbefa1dcf6e72fddb7baac1400c4dee Mon Sep 17 00:00:00 2001
From: Ning Sun <[email protected]>
Date: Sat, 6 Jun 2026 18:51:59 -0700
Subject: [PATCH] Protocol negotiation sends full version instead of minor
---
doc/src/sgml/protocol.sgml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 49f81676712..87dbc09af07 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -602,8 +602,8 @@
<para>
The server does not support the minor protocol version requested
by the client, but does support an earlier version of the protocol;
- this message indicates the highest supported minor version. This
- message will also be sent if the client requested unsupported protocol
+ this message indicates the highest supported version. This message
+ will also be sent if the client requested unsupported protocol
options (i.e., beginning with <literal>_pq_.</literal>) in the
startup packet.
</para>
@@ -5450,8 +5450,8 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
<term>Int32</term>
<listitem>
<para>
- Newest minor protocol version supported by the server
- for the major protocol version requested by the client.
+ Newest protocol version supported by the server for the
+ major protocol version requested by the client.
</para>
</listitem>
</varlistentry>
--
2.54.0
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [PATCH] Correct the version sent in protocol negotiation
2026-06-07 02:00 [PATCH] Correct the version sent in protocol negotiation Ning Sun <[email protected]>
@ 2026-06-07 05:06 ` Laurenz Albe <[email protected]>
2026-06-07 07:40 ` Re: [PATCH] Correct the version sent in protocol negotiation Ning Sun <[email protected]>
0 siblings, 1 reply; 3+ messages in thread
From: Laurenz Albe @ 2026-06-07 05:06 UTC (permalink / raw)
To: Ning Sun <[email protected]>; [email protected]
On Sun, 2026-06-07 at 10:00 +0800, Ning Sun wrote:
> Our protocol doc describes protocol negotiation message will send latest
> minor version. However that field is a 4-byte one. The actual
> implementation sends full version including the major part:
>
> The patch included just clarifies this behavior by removing "minor" from
> "newest minor version".
To my understanding, the "minor version" is the entire version *including*
the last number, like 18.4 (and not only .4).
In this, I seem to be in agreement with
https://www.postgresql.org/support/versioning/
To me, removing the "minor" makes the text less clear. If we change that
at all, perhaps a wording like "the full version, including the minor
release" would remove any ambiguity.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: [PATCH] Correct the version sent in protocol negotiation
2026-06-07 02:00 [PATCH] Correct the version sent in protocol negotiation Ning Sun <[email protected]>
2026-06-07 05:06 ` Re: [PATCH] Correct the version sent in protocol negotiation Laurenz Albe <[email protected]>
@ 2026-06-07 07:40 ` Ning Sun <[email protected]>
0 siblings, 0 replies; 3+ messages in thread
From: Ning Sun @ 2026-06-07 07:40 UTC (permalink / raw)
To: Laurenz Albe <[email protected]>; [email protected]
I see. The "minor version" has its own meaning in postgres context.
That makes sense. Thank you for clarification, Laurenz.
On 07/06/2026 13:06, Laurenz Albe wrote:
> On Sun, 2026-06-07 at 10:00 +0800, Ning Sun wrote:
>> Our protocol doc describes protocol negotiation message will send latest
>> minor version. However that field is a 4-byte one. The actual
>> implementation sends full version including the major part:
>>
>> The patch included just clarifies this behavior by removing "minor" from
>> "newest minor version".
> To my understanding, the "minor version" is the entire version *including*
> the last number, like 18.4 (and not only .4).
>
> In this, I seem to be in agreement with
> https://www.postgresql.org/support/versioning/
>
> To me, removing the "minor" makes the text less clear. If we change that
> at all, perhaps a wording like "the full version, including the minor
> release" would remove any ambiguity.
>
> Yours,
> Laurenz Albe
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2026-06-07 07:40 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-06-07 02:00 [PATCH] Correct the version sent in protocol negotiation Ning Sun <[email protected]>
2026-06-07 05:06 ` Laurenz Albe <[email protected]>
2026-06-07 07:40 ` Ning Sun <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox