Re: Implementing SQL/PSM for PG 8.2 - debugger

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(at)skype(dot)net>
>
>
>