On K, 2005-06-29 at 10:33 +0100, Mark Cave-Ayland wrote:
> Hi guys,
> > I lean with you and Tom. While running it over the same libpq protocol
> > would be helpful in some ways, it would have a lot of drawbacks and
> > would really change the function of libpq. I think a separate debugging
> > protocol is in order.
> Just putting on my network hat for a moment... Would an approach be to come
> up with a generic encapsulation protocol, similar in principle to PPP, in
> which we could run any protocols we wanted?
That's what I also thought, but was too busy/lazy to write up :)
> If we had something like a PGSQL Encapsulation Protocol (PGEP) used to
> transfer all data between a PostgreSQL client/server, then we can use this
> to tunnel libpq requests as they are at the moment through to the other
also, additional channels un PGEP could be initiated in both directions,
and things like NOTIFY could be put in a different channel.
> However, it would also mean that people could add any other protocols
> as they see fit for debugging, statistics and all sorts of things that
> people have yet to think of.
One example would be connection keepalive protocol , run over its own
channel in PGEP and used in case TCP link has a tendency to fail.
This should be run from server to client during idle periods, just to
see if client is still there.
> Obviously this would require a client/server interface change so it's not to
> be taken lightly, but I thought I'd mention it since people have mentioned
> the possibility of changes to the FE/BE protocol.
As protocol is negotiated at startup anyway, this is a change that could
be done in a backward compatible manner .
Hannu Krosing <hannu(at)skype(dot)net>
In response to
pgsql-hackers by date
|Next:||From: Qingqing Zhou||Date: 2005-06-29 10:09:34|
|Subject: Re: GiST concurrency commited|
|Previous:||From: Martin Münstermann||Date: 2005-06-29 09:41:04|
|Subject: symbol name clash with libpq.so: md5_hash|