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
> side.
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 <[EMAIL PROTECTED]>
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
