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

Re: FE/BE Protocol - Specific version

From: Richard Huxton <dev(at)archonet(dot)com>
To: Bruce Badger <bruce_badger(at)badgerse(dot)com>,PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: FE/BE Protocol - Specific version
Date: 2003-08-29 18:54:32
Message-ID: 200308291954.32708.dev@archonet.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Friday 29 August 2003 15:37, Bruce Badger wrote:
> On Fri, 2003-08-29 at 23:35, Tom Lane wrote:
> > Rod Taylor <rbt(at)rbt(dot)ca> writes:
> > >> So, being able to stop connections trying to use old protocol versions
> > >> would be very helpful in this case.
> > >
> > > Wouldn't it be better to have StORE run a select version() after
> > > connecting?
> >
> > Well, his point is that old versions of his client code wouldn't know to
> > do that.  However, I don't think that what he's suggesting is a suitable
> > answer either --- he wants to rely on a chance coincidence, namely that
> > we're upgrading the FE/BE protocol at the same time that he wants to
> > make an incompatible application-level change.

> So, if it did come to pass that rejecting connections on the basis of
> protocol version was possible, then I could fix the broken encoding
> implementation.  Otherwise, I think I'll have to wait for the next
> chance coincidence.
>
> ... unless anyone has any better ideas? :-/

1. Run "new" versions of the database on a different port - only the new 
client will know to look there.
2. Write a small proxy to simulate #1 (in case PG is serving other clients) - 
only allow access to the StORE db from localhost
3. Write a small proxy to determine which version of the protocol is in use, 
and allow/deny access as required.

-- 
  Richard Huxton
  Archonet Ltd

In response to

pgsql-hackers by date

Next:From: Robert TreatDate: 2003-08-29 20:39:39
Subject: Re: FE/BE Protocol - Specific version
Previous:From: Ron JohnsonDate: 2003-08-29 17:31:27
Subject: Re: Hardware recommendations to scale to silly load

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