Skip site navigation (1) Skip section navigation (2)

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

From: Mikko Tiihonen <mikko(dot)tiihonen(at)nitorcreations(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: oliver(at)opencloud(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, mmoncure(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [JDBC] Optimize postgres protocol for fixed size arrays
Date: 2011-11-24 18:54:43
Message-ID: 4ECE92F3.9000402@nitorcreations.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-jdbc
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

In response to

Responses

pgsql-hackers by date

Next:From: Jeff DavisDate: 2011-11-24 19:01:52
Subject: Re: Obstacles to user-defined range canonicalization functions
Previous:From: Pavel StehuleDate: 2011-11-24 17:30:03
Subject: proposal: use errcontext for custom exception too

pgsql-jdbc by date

Next:From: Heikki LinnakangasDate: 2011-11-24 19:40:30
Subject: Re: CallableStatement PostgreSQL Error:A CallableStatement was executed with an invalid number of parameters
Previous:From: JavaNoobieDate: 2011-11-24 04:13:08
Subject: CallableStatement PostgreSQL Error:A CallableStatement was executed with an invalid number of parameters

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group