This is an interesting suggestion, particularly the addition of
additional connections for management
However it does require all clients rewrite (yet again ) their
connection code.
My reasoning for suggesting a separate port for debugging are:
1) no changes to existing clients ( this probably could be done by
extending the existing protocol )
2) Ability to run your existing applications, not just psql, but any
application and remotely debug without interfering
with the current connection data.
3) Relatively easy to create (name your favorite language) debuggers
4) Seems easier to connect, and disconnect from the process of interest.
Dave
On 29-Jun-05, at 6:06 AM, Hannu Krosing wrote:
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 7: don't forget to increase your free space map settings
