public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tatsuo Ishii <[email protected]>
To: [email protected]
Subject: Re: Feature: implement NegotiateProtocolVersion message
Date: Thu, 10 Jul 2025 19:38:13 +0900 (JST)
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
>> NegotiateProtocolVersion message is a message sent from backend to
>> frontend. After a startup message is sent from frontend to backend,
>> and the minor protocol version in the startup message is not supported
>> by the backend, the backend sends back a NegotiateProtocolVersion
>> message along with the latest minor protocol version it supports.
>>
>> For example, PostgreSQL 18 client could request a protocol version 3.2
>> against PostgreSQL 17 server, then the PG17 server sends back the
>> NegotiateProtocolVersion message with protocol version 3.0 since it
>> does not support 3.2. If the PG18 client accepts it, then from now on
>> the protocol version 3.0 is used for the communication.
>>
>> At this point, as PG18's psql (or libpq) uses protocol version 3.0 by
>> default, PG18 (or before) server will not send back the
>> NegotiateProtocolVersion message because the versions support 3.0.
>>
>> The only case when 3.2 is used, is PG18's psql (or libpq) uses a
>> connection option max_protocol_version (or environment variable
>> PGMAXPROTOCOLVERSION) being set to "3.2". I don't know if the case
>> happen in the wild after PG18 is released, but I would like to prepare
>> for the situation by implementing NegotiateProtocolVersion message in
>> Pgpool-II 4.7. Attached patch does followings for the purpose.
>>
>> - Add ProcessNegotiateProtocol() to pool_do_auth() to process the
>> message while handling a startup message. It reads the message from
>> all backend, then forward it to frontend. The message is saved in
>> ConnectionInfo for the case below. It also save the major and minor
>> protocol version after negotiation to POOL_CONNECTION_POOL_SLOT for
>> later use. The version numbers are also saved to ConnectionInfo so
>> that pcp_proc_info shows them.
>>
>> - When a client connects to pgpool, it looks for cached connections in
>> the connection: pgpool tries to match the startup message with the
>> one in the connection pool. Since the startup message in the
>> connection pool is saved at the time when the client connects to
>> pgpool, it is possible that two connection cache are created with
>> same user and database. Suppose there's a connection cache with a
>> startup message having protocol version 3.0, and a new client tries
>> to connect to pgpool using protocol version 3.2. Pgpool looks for a
>> connection cache with the startup message having protocol version
>> 3.2, not 3.0. As a result a new connection cache entry is created
>> with protocol version 3.2.
>>
>> - When a client uses the connection pool, the saved
>> NegotiateProtocolVersion message is sent to frontend to emulate the
>> protocol negotiation.
>>
>> - The frontend/backend protocol 3.2 changes the BackendKeyData message
>> format but it's not implemented in this patch yet. I will work on it
>> later on.
>
> Attached is the v2 patch fixing bug in v1. Also some protocol related
> macros are imported from PostgreSQL.
v2 patch pushed.
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: Feature: implement NegotiateProtocolVersion message
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox