Re: Implementing SQL/PSM for PG 8.2 - debugger

From: Hannu Krosing <hannu(at)skype(dot)net>
To: Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Cc: "'Jonah H(dot) Harris'" <jharris(at)tvi(dot)edu>, 'Dave Cramer' <pg(at)fastcrypt(dot)com>, 'Pavel Stehule' <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>, 'Tom Lane' <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 'Neil Conway' <neilc(at)samurai(dot)com>, 'Jan Wieck' <JanWieck(at)Yahoo(dot)com>, 'Denis Lussier' <denis(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Implementing SQL/PSM for PG 8.2 - debugger
Date: 2005-06-29 10:06:48
Message-ID: 1120039609.4844.9.camel@fuji.krosing.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Qingqing Zhou 2005-06-29 10:09:34 Re: GiST concurrency commited
Previous Message Martin Münstermann 2005-06-29 09:41:04 symbol name clash with libpq.so: md5_hash