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

Re: Proposal for debugging of server-side stored procedures

From: Thomas Hallgren <thomas(at)tada(dot)se>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org,Mark Cave-Ayland <m(dot)cave-ayland(at)webbased(dot)co(dot)uk>
Subject: Re: Proposal for debugging of server-side stored procedures
Date: 2006-05-29 19:07:26
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> Thomas Hallgren <thomas(at)tada(dot)se> writes:
>> I think this is a bad idea. PL/Java will use either shared memory or a
>> socket to attach and as you already mentioned, when using C, a gdb
>> will attach directly using the pid. I wouldn't be too surprised if
>> Perl, Python, and PHP all have a similar solution and thus have no
>> benefit from additions to the FE/BE protocol. IMO, debugging should be
>> language specific and take place in a separate channel. There's no
>> gain whatsoever mixing it with the FE/BE protocol.
> It may well be that for plperl and friends we can kick the problem off
> to language-specific debuggers --- indeed, one of the first things we
> need to do is look at those to see what we can avoid reinventing.
> But what of plpgsql?
Ideally, all pl's should use the same protocol. It should be language agnostic and allow 
different regions of the code to origin from different languages. That way, it would be 
possible to single step a plpgsql function that in turn calls a function in pljava. 
Incidentally, the JDWP (Java Debug Wire Protocol) was designed to do just that. But I think 
it would be very complicated to cross language boundaries even if we did use that.

The JDWP and the architecture that surrounds it might be a good source for inspiration 
though. See:

> Also, any solution of this type probably requires that the person doing
> debugging have database superuser access (in fact, be logged directly
> into the server machine as the postgres user).  It'd be nice to have an
> approach that could be used by non-superusers to debug their trusted-PL
> functions.
Indeed. In my case, it's a matter of who starts the VM and what options that are passed to 
it (given certain options, the JVM will listen to a port or a semaphore that controls a 
region of shared memory). That in turn is controlled using GUC settings so for PL/Java I 
think it would be possible to set it up that way.

Thomas Hallgren

In response to


pgsql-hackers by date

Next:From: YannickDate: 2006-05-29 19:20:00
Subject: Compile libpq with vc8
Previous:From: Tom LaneDate: 2006-05-29 18:29:06
Subject: Re: Proposal for debugging of server-side stored procedures

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