Thread: Re: [JDBC] Optimize postgres protocol for fixed size arrays

Oliver Jowett  wrote:

> Can we get a mechanism for minor protocol changes in this future
> version? Something as simple as exchanging a list of protocol
> features during the initial handshake (then use only features that
> are present on both sides) would be enough. The difficulty of
> making any protocol changes at the moment is a big stumbling block.

I've been thinking the same thing.  Any new protocol should include a
way for each side to publish a list of what it can accept from the
other during initial handshaking.

> (You could probably retrofit that to the current protocol version)

Perhaps.  It would be great if both sides could recognize the case
where the "feature negotiation" was absent and use a default feature
list for the protocol available on the other end.

-Kevin

On 11/24/2011 02:36 AM, Kevin Grittner wrote:
> Oliver Jowett  wrote:
>
>> Can we get a mechanism for minor protocol changes in this future
>> version? Something as simple as exchanging a list of protocol
>> features during the initial handshake (then use only features that
>> are present on both sides) would be enough. The difficulty of
>> making any protocol changes at the moment is a big stumbling block.
>
> I've been thinking the same thing.  Any new protocol should include a
> way for each side to publish a list of what it can accept from the
> other during initial handshaking.
>
>> (You could probably retrofit that to the current protocol version)
>
> Perhaps.  It would be great if both sides could recognize the case
> where the "feature negotiation" was absent and use a default feature
> list for the protocol available on the other end.

What about a hand-shake protocol based on simple binary-protocol minor
version instead of features. We keep the v3 protocol as is but can
add cumulative conditionally enabled features when we bump the minor
version.

The hand shake requires that the server sends a parameter back with
it's highest supported minor version:
FE=> StartupPacket
<=BE ParameterStatus(binary_minor = 23)

And the client can send any number between 1<=binary_minor back to
enable newer protocol versions and/or limit what the server sends
FE=> Execute(SET binary_minor = 20)

To keep full backwards compatibility:
1) if backend does not send a binary_minor parameter on connection the
    highest supported minor version is assumed to be 0 (current format)
2) the backend assumes the active minor version is 0 unless the
    SET binary_minor is received

I think bumping a minor version is better than feature flags because:
1) the hand shake is simpler and faster
2) coding is easier as all previous features are known to be supported
    and active when implementing feature+1

I'm not exactly sure about the COPY BINARY feature Tom mentioned. But
probably we could prefix the data with the int4 containing the
minor version?

-Mikko

On 25 November 2011 07:54, Mikko Tiihonen
<mikko.tiihonen@nitorcreations.com> wrote:

> <=BE ParameterStatus(binary_minor = 23)
> FE=> Execute(SET binary_minor = 20)

Yeah this was almost exactly what I was thinking about how to retrofit
it, except it might be clearer to have, say, "supported_binary_minor"
(read-only, advertised by the server on startup) vs. "binary_minor"
(read-write, defaults to 0) as otherwise you have special behavior for
just one parameter where the advertised version doesn't actually match
the currently-set version.

Re list vs. always-incrementing minor version, you could just use an
integer and set bits to represent features, which would keep it simple
but also let clients be more selective about which features they
implement (you could support feature 21 and 23 without supporting 22)

Oliver