On Wed, 2005-09-07 at 22:02 -0400, Tom Lane wrote:
> Given that it'd be guaranteed not to work with any existing server
> versions, I find the usefulness a bit debatable...
Indeed =(. However, "older servers" could be easily detected then if the
returned message type is 'E'. If 'E' is returned, it would likely be on
a pre "8.x server running 2.0 and/or 3.0". Thus signalling the client
connection code to fall back on "old-style version detection", if need
be. Alas, this would, of course, require yet another connection
expenditure for any so called "pre-version list supporting servers".
> In particular I disagree with the premise that clients should expend an
> extra connection setup/teardown cycle to find out which protocol
> versions the server supports. We change protocol versions seldom enough
> that I think the optimal strategy is "try the newest version you know
> of, then back off one at a time until it works". This is always optimal
> if the server is newer than the client, and it's only pessimal if the
> server is much older than the client --- how often does that happen?
[Assuming you're not referring to connection attempts to the
"pre-version list supporting servers"]
Why does it have to be torn down? I imagine that it could easily be an
extra, optional part of connection negotiation. Wait for startup packet,
If Version(0,0), Send PQ version list, wait for real startup packet,
Else take it as the "real startup packet", or ssl neg message, or etc.
If I implied that it should be torn down entirely, it was probably due
to how I was planning to manage the initial connection that I establish
to a server to validate that a connection can actually be made and
resolve any/some server specific issues(int timestamps, etc). Although,
this is all specific to the implementation that I'm brewing.
(not sure about all the specifics yet, as I've just been toying with the
idea)
> To put it more concretely: there are currently only two protocol
> versions in live use (V1 died a long time ago). If you try V3 and then
> V2, you will expend either one or two connection cycles, with the
> average converging towards one as time passes and more people update
> their servers. If you probe for the right answer and then do it, you
> will always expend two connection cycles. That is a win how exactly?
Like I asked above, why does it have to be done in two connection
cycles? I'm assume by connection cycle you are referring to reopening
the socket, or...?
--
Regards, James William Pye
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
