Re: Proposal for debugging of server-side stored procedures - Mailing list pgsql-hackers

From Mark Cave-Ayland
Subject Re: Proposal for debugging of server-side stored procedures
Date
Msg-id 200606121613.k5CGDSr05287@webbased16.localdomain
Whole thread Raw
In response to Re: Proposal for debugging of server-side stored procedures  (Thomas Hallgren <thomas@tada.se>)
Responses Re: Proposal for debugging of server-side stored procedures  (Lukas Smith <smith@pooteeweet.org>)
List pgsql-hackers
> -----Original Message-----
> From: Thomas Hallgren [mailto:thomas@tada.se]
> Sent: 11 June 2006 10:07
> To: Mark Cave-Ayland
> Cc: pgsql-hackers@postgresql.org
> Subject: Re: Proposal for debugging of server-side stored procedures

Hi Tom,

(cut)

> Obviously I'm not a Perl nor Python hacker. I just find it hard to believe
> that languages
> that has matured over a decade doesn't have a remote debug option that can
> be used. Sockets,
> shared-memory, pipes, or whatever. You will be able to attach to it
> somehow given it's been
> launched with the correct flags.
> 
> I think you're wrong in thinking that client/server based debugging is in
> any way unusual.
> Googling for perl+debug+remote tells me that client/server based Perl
> debugging is common.
> There are a number of solutions. The same is true for Python.

It's not unusual, it's just that the standard libraries included with
Perl/Python contain practically no support for remote debugging - while they
both provide interfaces for you to write you own replacement, there doesn't
seem to be a standard for remote debugging other than Xdebug.

(cut)

> In my experience you have two use-cases.
> 
> 1. You debug during development and have either have your own database
> instance to play
> around with or a shared sandbox database where the security is very low.
> 2. You debug a running instance on a live server and the sysadmin is well
> aware what you're
> doing. You will be given required privileges as needed.
> 
> I would argue that the times when security becomes an issue when debugging
> are extremely
> rare and not worth spending lots of time and effort on. It is enough to
> prevent anyone but a
> super-user (or even a sysadmin) to start a remote debug session.

True, although there are times for example in our web applications where we
need to debug as a non super-user since the web user accessing the database
obviously doesn't have super-user rights. In the case of DBGP this could be
a case of allowing only the super-user to set the remote host/port while
allowing any user to initiate a debug session. At least in the case the
administrator would be aware of the implications of enabling debugging in
this way.

(cut)

> > A promising option at the moment would be to implement the DBGP protocol
> for
> > Perl/Python/Tcl as suggested by Lukas, mainly because it appears
> ActiveState
> > have already written the modules to do this (see
> > http://aspn.activestate.com/ASPN/Downloads/Komodo/RemoteDebugging).
> 
> There you go! Perl, PHP, Python, and Tcl all taken care of. IDE and all!

I've been having a look at the licensing and it appears that the server side
libraries are licensed under the Artistic License
(http://www.opensource.org/licenses/artistic-license.php). Looking at the
wording of the license I can't see that there would be much of a problem
including these with PostgreSQL to give "out of the box" DBGP support, but
with the option of allowing the user to override the defaults per language
in postgresql.conf - this would allow, say, for Andrew to run ptkdb as an
alternative while normal users could just go with the defaults. Can anyone
see any problems with this? If not, I'd be happy to approach the
ActiveState/Xdebug people to see if this is feasible.

The only remaining angle would be to implement the Xdebug protocol for
plpgsql in C which would probably be the most time-consuming aspect of the
project :)

(cut)

> I'd use the Komodo IDE and implement the ability to start the PL using a
> GUC setting per my
> original suggestion (with super-user requirement). Trivial solution,
> minimum effort, and
> very useful. KISS principle.
> 
> It would be great if we could agree on a GUC flag (or flags) that would
> control debugging
> for all PL's. At present, all PL implementors must use their own (module
> specific) flags.

I'm not quite sure what you had in mind from your previous email - could you
elaborate more on this?


Kind regards,

Mark.

------------------------
WebBased Ltd
17 Research Way
Plymouth
PL6 8BT

T: +44 (0)1752 797131
F: +44 (0)1752 791023

http://www.webbased.co.uk   
http://www.infomapper.com
http://www.swtc.co.uk  

This email and any attachments are confidential to the intended recipient
and may also be privileged. If you are not the intended recipient please
delete it from your system and notify the sender. You should not copy it or
use it for any purpose nor disclose or distribute its contents to any other
person.






pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),
Next
From: "Joshua D. Drake"
Date:
Subject: Re: TODO: Add pg_get_acldef(), pg_get_typedefault(),