Re: Proposal for debugging of server-side stored procedures

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Thomas Hallgren <thomas(at)tada(dot)se>
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 18:29:06
Message-ID: 15787.1148927346@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Hallgren 2006-05-29 19:07:26 Re: Proposal for debugging of server-side stored procedures
Previous Message Magnus Hagander 2006-05-29 18:26:00 Re: anoncvs still slow