Re: Implementing SQL/PSM for PG 8.2 - debugger

From: Dave Cramer <pg(at)fastcrypt(dot)com>
To: Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Neil Conway <neilc(at)samurai(dot)com>, "Jonah H(dot) Harris" <jharris(at)tvi(dot)edu>, 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-28 16:54:49
Message-ID: 8CE94C03-F12C-4639-B5AE-73E568DD25A0@fastcrypt.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Pavel,

I am in agreement with Tom here, we should use a separate port, and
protocol specifically designed for this.

My understanding is that this protocol would be synchronous, and be
used for transferring state information, variables, etc back and forth
whereas the existing protocol would still be used to transfer data
back and forth

Dave
On 28-Jun-05, at 10:36 AM, Pavel Stehule wrote:

> On Tue, 28 Jun 2005, Tom Lane wrote:
>
>
>> Pavel Stehule <stehule(at)kix(dot)fsv(dot)cvut(dot)cz> writes:
>>
>>>> What do you think you need for enhanced protocol ?
>>>>
>>
>>
>>> What I need? Some like synchronous elog(NOTICE,''), which can
>>> return some
>>> user's interaction, if it's possible. I didn't find how I do it with
>>> current set of messages. But my knowleadges of protocol are minimal.
>>>
>>
>> It'd probably be smarter to manage the debugging across a separate
>> connection, so that you could carry out debugging without requiring
>> sophisticated support for it inside the client program. If it's
>> single-connection then it will be essentially impractical to debug
>> except from a few specialized clients such as pgadmin; which will
>> make it hard to investigate behaviors that are only seen under load
>> from a client app.
>>
>
> I don't think it. Debug process halt query process in bouth variants -
> remote | protocol. Remote debugging has one advance. I can monitor any
> living plpgsql process, but I have to connect to some special port,
> and it
> can be problem. Protocol debugging can be supported libpq, and all
> clients
> libpq can debug. But is problem if PostgreSQL support bouth variants?
>
> btw: debuging have to be only for some users,
> GRANT DEBUG ON LANGUAGE plpgsql TO ..
>
> For me, is better variant if I can debug plpgsql code in psql console.
> Without spec application. I don't speak so spec application don't
> have to
> exists (from my view, ofcourse).
>
> Maybe:
> set debug_mode to true; -- if 't' then func stmt has src
> reset function myfce(integer, integer); -- need recompilation
> create breakpoint on myfce(integer, integer) line 1;
> select myfce(10,10);
> dbg> \l .. list current line
> \c .. continue
> \n .. next stmt
> \L .. show src
> \s .. show stack
> \b .. switch breakpoint
> \q .. quit function
> select myvar+10 .. any sql expression
> variable .. print variable
> \c
> myfce
> -----
> 10
>
> that's all. Maybe I have big fantasy :).
>
> Regards
> Pavel
>
> + small argument: if psql support debug mode, I don't need leave my
> emacs
> postgresql mode.
>
>
>
>
>>
>> I don't know exactly how to cause such a connection to get set up,
>> especially remotely. But we should try to think of a way.
>>
>> regards, tom lane
>>
>>
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to
> majordomo(at)postgresql(dot)org)
>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message PFC 2005-06-28 16:58:32 Re: ENUM like data type
Previous Message Tom Lane 2005-06-28 16:29:22 Role syntax (or, SQL99 versus sanity)