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

Re: Loading the PL/pgSQL debugger (and other plugins)

From: "Hiroshi Saito" <z-saito(at)guitar(dot)ocn(dot)ne(dot)jp>
To: "korry" <korryd(at)enterprisedb(dot)com>,"John DeSoi" <desoi(at)pgedit(dot)com>
Cc: "PostgreSQL-development Hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Loading the PL/pgSQL debugger (and other plugins)
Date: 2006-07-21 23:28:48
Message-ID: 038701c6ad1d$6b1ac090$01324d80@hiroshi5jz7dqj (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Hi korry-san.

From: "korry" 

> > I'm unqualified to comment on the server side design, but I was 
> > wondering if there was consensus on how the client interface to the 
> > debugger would work. From previous threads I saw DBGP mentioned 
> > (, but I don't recall seeing any final 
> > commitment to it.
> The patch that I'll be submitting for 8.2 will implement a way to 
> instrument PL/pgSQL (and that idea can be extended to other PL 
> languages).  'Instrumentation' can mean different things - it may be a 
> debugger, a profiler, a coverage analyzer, a tracer, ... 

I can regard it as very great. probably, It is expected that workstation 
(edb-debugger) is realizable with an addition of some language parser.:-)

> EnterpriseDB has developed a few plugins that we'll be contributing soon 
> (a debugger, a profiler, and a tracer).  The debugger is by far the 
> largest plugin that we've developed and we implemented it before we had 
> the idea to use a modular architecture (we're still in the process of 
> converting the debugger to modular form, at the moment it's pretty 
> heavily integrated into the PL/pgSQL interpreter).  As soon as we get a 
> patch in for the plugin architecture, we'll open-source at least one or 
> two of the plugins so others can use them and/or write more (the 
> debugger will take a little longer). 
> That means that we (i.e. the community) haven't made a firm commitment 
> to the debugger client protocol.  I can tell you a little about the 
> protocol that we are currently using, but it may change by the time 
> we're ready to open-source the debugger.  I gave a presentation at the 
> anniversary summit that described the overall architecture and also 
> showed the client/server protocol - the slides and audio should be 
> available at the conference web site "real soon now". 

Your session was very wonderful. People who were not able to hear it will be seen.

> The most important part, from your perspective (assuming that you might 
> want to add a debugger to pgEdit), is the method that a debugger client 
> application uses to interact with the debugger server.  That's done 
> through a collection of server-side functions that you can call from any 
> libpq application.  For example, to set a breakpoint, you would:
>     SELECT * FROM pldbg_set_breakpoint( sessionHandle, functionOID, 
> lineNumber, processID );
> to step/over:
>     SELECT * FROM pldbg_step_over( sessionHandle );
> to step/into:
>     SELECT * FROM pldbg_step_into( sessionHandle );
> to get a copy of all local variables:
>     SELECT * FROM pldbg_get_variables( sessionHandle, stackFrame );
> and so on.  There are a few functions that you can call to attach your 
> debugger client to a target server and to set global breakpoints.
> I'll be posting more information as we get closer to releasing this stuff. 

This regards me as a very great contribution.! 
As for me, the feeling of workstation (edb-debugger) was pleased very much.
I consider it so that often to pgAdmin. Then, I am looking forward to the evolution.:-)


Hiroshi Saito

In response to

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2006-07-21 23:39:20
Subject: Re: [PATCHES] Generic Monitoring Framework with DTrace patch
Previous:From: Andrew DunstanDate: 2006-07-21 22:49:49
Subject: Re: Transaction Speed and real time database

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