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

From: korry <korryd(at)enterprisedb(dot)com>
To: 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 18:21:11
Message-ID: BAY101-DAV1047F8E91D05750B49385FD6660@phx.gbl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> 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
> (http://xdebug.org/docs-dbgp.php), 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, ...

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".

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.

-- Korry

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-07-21 18:28:49 Re: Loading the PL/pgSQL debugger (and other plugins)
Previous Message John DeSoi 2006-07-21 17:35:11 Re: Loading the PL/pgSQL debugger (and other plugins)