Tom Lane wrote:
Thomas Hallgren <[EMAIL PROTECTED]> 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: http://java.sun.com/j2se/1.5.0/docs/guide/jpda/architecture.html.
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.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
