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
|
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: