Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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


pgsql-hackers by date

Next:From: Qingqing ZhouDate: 2005-06-29 10:09:34
Subject: Re: GiST concurrency commited
Previous:From: Martin M√ľnstermannDate: 2005-06-29 09:41:04
Subject: symbol name clash with md5_hash

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group