Thread: PQ versions request message
I have been writing a PQ client and I have come to think that a "supported PQ versions request startup packet" would be useful to client authors. That is, sending a StartupPacket(Version(0, 0))(or whatever) would return a message containing a list of supported PQ versions, and maybe the server version as well. Having the said feature would allow client authors to select the connection code based on the versions returned, rather than using a trial and error process. It also gives the client the ability to quickly error out and notify the user that it cannot connect to the server if the client doesn't support any of the server versions. I find the trial and error process unseemly as it could require code to be loaded that simply does not need to be loaded--of course, making assumptions about the client design(this would likely be the case for my client). In addition, the trial and error process could be time consuming depending on how the connection to the server is established, thus further decreasing the appeal of the trial and error process(hrm, this may not be a useful criticism of t&e if pg keeps the pipe open until the client sends a suitable startup packet?). Although, I do see that the trial and error process would only need to happen once(per process, I figure) if the client author cached the code selection information about a given server. Thoughts? Has this been proposed/shot down before? -- Regards, James William Pye
James William Pye wrote: > I have been writing a PQ client and I have come to think that a > "supported PQ versions request startup packet" would be useful to > client authors. That is, sending a StartupPacket(Version(0, 0))(or > whatever) would return a message containing a list of supported PQ > versions, This doesn't make sense to me, because a server does not have any version requirements on the client (aside from the protocol versions, which are negotiated automatically). > and maybe the server version as well. That is already available automatically. -- Peter Eisentraut http://developer.postgresql.org/~petere/
James William Pye <pgsql@jwp.name> writes:
> I have been writing a PQ client and I have come to think that a
> "supported PQ versions request startup packet" would be useful to client
> authors.
Given that it'd be guaranteed not to work with any existing server
versions, I find the usefulness a bit debatable...
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?
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?
regards, tom lane
On Thu, 2005-09-08 at 03:48 +0200, Peter Eisentraut wrote: > This doesn't make sense to me, because a server does not have any > version requirements on the client (aside from the protocol versions, > which are negotiated automatically). The use case primarily applies to custom clients(non-libpq, atm) that support multiple PQ versions that may be implemented in separate modules/libraries. (Avoid loading client-2.0 code for a 3.0 connection, and/or future versions.) libpq "automatically negotiates" the version using trial and error, effectively(assume 3.0 by sending 'S', if 'E', fallback to 2.0, and reestablish the connection, apparently). > > and maybe the server version as well. > > That is already available automatically. Yes, but, AFAIK, only after the protocol has been negotiated and authentication is complete. Really, I'm not sure if such a feature should include the server version as selecting feature implementations based on it is probably a bad idea(TM). -- Regards, James William Pye
James William Pye wrote: > The use case primarily applies to custom clients(non-libpq, atm) that > support multiple PQ versions that may be implemented in separate > modules/libraries. (Avoid loading client-2.0 code for a 3.0 connection, > and/or future versions.) > > libpq "automatically negotiates" the version using trial and error, > effectively(assume 3.0 by sending 'S', if 'E', fallback to 2.0, and > reestablish the connection, apparently). The JDBC driver does exactly the same (or you can explicitly specify a protocol version to use) and is effectively loading code on demand anyway, being Java -- but I've seen no problems with the current approach. I think you're trying tho fix a problem that doesn't exist. -O
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
James William Pye <pgsql@jwp.name> writes:
> 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...?
You're right, it wouldn't be necessary to tear down the socket --- but
it *would* be necessary to have two network round trips. And the point
remains that in most scenarios the client and server will be of similar
vintages and so wish to speak the same protocol version anyway, so most
of the time the extra probe would be useless. I think you're trying to
optimize the uncommon case at the expense of the common case.
regards, tom lane
On Thu, 2005-09-08 at 09:17 -0400, Tom Lane wrote: > You're right, it wouldn't be necessary to tear down the socket --- but > it *would* be necessary to have two network round trips. And the point > remains that in most scenarios the client and server will be of similar > vintages and so wish to speak the same protocol version anyway, so most > of the time the extra probe would be useless. I think you're trying to > optimize the uncommon case at the expense of the common case. The feature, being optional, does not always require any extra expense. The expense is only incurred when the feature is used; those who use are those who pay. For those users, I imagine this would normally be once per host per process, and only if the user of the client does not explicitly specify the PQ version in the first place. AFA the likelihood of client and servers being of similar vintages, I imagine that you are right here. Although, I would rather not play a guessing game if I didn't have to, and the backend very well has the ability to give me the information that I need to avoid any such thing. The point is to give client authors the ability to authoritatively resolve ambiguity that may exist in multiversion supporting clients and to do so without any version specific code(or at a minimum wrt older servers) or fingerprinting of any sort. -- Regards, James William Pye
James William Pye <pgsql@jwp.name> writes:
> The point is to give client authors the ability to authoritatively
> resolve ambiguity that may exist in multiversion supporting clients and
> to do so without any version specific code(or at a minimum wrt older
> servers) or fingerprinting of any sort.
Had we had such a facility from the beginning, it would indeed have that
benefit. But unless you are going to start out by dropping client-side
support for all extant server versions, you will not get any such
benefit; you'll still need retry code. So I still think this isn't
really worth the trouble it would take to implement.
Also, you keep referring to caching the result on the client side and
re-using it across multiple connections --- but you can do that now,
so why is that an argument in favor?
regards, tom lane
On Thu, 2005-09-08 at 16:27 -0400, Tom Lane wrote: > Had we had such a facility from the beginning, it would indeed have that > benefit. But unless you are going to start out by dropping client-side > support for all extant server versions, you will not get any such > benefit; you'll still need retry code. So I still think this isn't > really worth the trouble it would take to implement. The benefit will come when extant server versions become antiquated. AFA difficulty with the implementation is concerned, I wouldn't bother with anything except the backend. libpq-fe can wait until said antiquation occurs, and I imagine the backend work being 40 lines or so, no? > Also, you keep referring to caching the result on the client side and > re-using it across multiple connections --- but you can do that now, > so why is that an argument in favor? Not so much favor, but, rather, it was to target your complaint about the two required round-trips involved in connection negotiation with a version query. I was trying to ease that distaste by showing that if such ambiguity existed where resolution were necessary, it would/should only need to be done once(save various exceptions, of course). -- Regards, James William Pye