Date: Wed, 30 Oct 2024 20:34:55 +0900 (JST)
Message-Id: <20241030.203455.1272396392870662989.ishii@postgresql.org>
To: postgres@jeltef.nl
Cc: peter@eisentraut.org, pgsql-hackers@postgresql.org
Subject: Re: protocol-level wait-for-LSN
From: Tatsuo Ishii <ishii@postgresql.org>
In-Reply-To: <CAGECzQStS3WViKunHBVLKuge5DgGdviwGsF_y1i1xvOmnQQ24A@mail.gmail.com>
References: <e76f3490-5b36-457e-bb80-2a4abdba70c9@eisentraut.org>
	<20241030.154919.859856957033404666.ishii@postgresql.org>
	<CAGECzQStS3WViKunHBVLKuge5DgGdviwGsF_y1i1xvOmnQQ24A@mail.gmail.com>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://www.postgresql.org/message-id/20241030.203455.1272396392870662989.ishii%40postgresql.org>
Precedence: bulk

> On Wed, 30 Oct 2024 at 07:49, Tatsuo Ishii <ishii@postgresql.org> wrote:
>> > I think one would have to define that somehow.  If it's useful, the
>> > additional fields of both extensions could be appended, in some
>> > defined order.  But this is an interesting question to think about.
>>
>> I think this kind of extension, which adds new filed to an existing
>> message type, should be implemented as v4 protocol.
> 
> Could you explain why you think a major version bump is needed? In
> what situation do you care about this. Because for my usecases (client
> implementations & pgbouncer) I don't think that would be necessary. If
> a client doesn't send the _pq_.wait_for_lsn protocol parameter, it
> will never receive this new version.

Yes, if there's only one extension for a message type, it would not be
a big problem. But if there's more than one extensions that want to
change the same type, problem arises as I have already discussed them
upthread.

> I don't really see a problem with having two protocol parameters
> change the same message. Yes, you have to define what the result of
> their combination is, but that seems trivial to do for additions of
> fields. You either define the first protocol parameter that was added
> to the spec, to add its field before the second. Or you could do it
> based on something non-time-dependent, like the alphabetic order of
> the protocol parameter, or the alphabetic order of the fields that
> they add.

That sounds far from trivial. So each extension needs to check if any
other extension which modifies the same message type is activated?
That requires each extension implementation to have built-in knowledge
about any conflicting extension. Moreover each extension may not be
added at once.  If extension Y is added after extension X is defined,
then implementation of X needs to be changed because at the time when
X is defined, it did not need to care about Y. Another way to deal
with the problem could be defining a new protocol message which
describes those conflict information so that each extensions do not
need to have such information built-in, but maybe it is too complex.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp