Обсуждение: Re: Implementing SQL/PSM for PG 8.2 - debugger
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? 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. 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. 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. Kind regards, Mark. ------------------------ WebBased Ltd 17 Research Way Tamar Science Park Plymouth PL6 8BT T: +44 (0)1752 797131 F: +44 (0)1752 791023 W: http://www.webbased.co.uk
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 <hannu@skype.net>
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 <hannu@skype.net> > > >
On K, 2005-06-29 at 08:00 -0400, Dave Cramer wrote: > 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: I'm not objecting to the idea of a separate "port", just suggesting one way to connect to that port using clients that are aware of the new PGEP protocol. the old ones can continue to work as they are. -- Hannu Krosing <hannu@skype.net>