Date: Thu, 10 Jul 2025 19:38:13 +0900 (JST)
Message-Id: <20250710.193813.29844576698476540.ishii@postgresql.org>
To: pgpool-hackers@lists.postgresql.org
Subject: Re: Feature: implement NegotiateProtocolVersion message
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: <20250709.160004.803224268243106375.ishii@postgresql.org>
References: <20250708.112133.1324153277751075866.ishii@postgresql.org>
	<20250709.160004.803224268243106375.ishii@postgresql.org>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20250710.193813.29844576698476540.ishii%40postgresql.org>
Precedence: bulk

>> 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