Thread: PL instrumentation plugin support (i.e. PL/pgSQL debugger infrastructure)
PL instrumentation plugin support (i.e. PL/pgSQL debugger infrastructure)
From
"korryd@enterprisedb.com"
Date:
The attached patch adds support for loadable instrumentation plugins for procedural languages (as discussed at the anniversary summit). It also adds plugin support to the PL/pgSQL language handler.
We are using this plugin mechanism to load the PL/pgSQL debugger on demand (the debugger is not part of this patch, the patch is just the infrastructure that we need to load various instrumentation plugins). We will also post some sample plugins (a PL/pgSQL profiler and a simple tracer), probably at the edb-debugger pgFoundry project site so you can see how to use the plugin mechanism.
A couple of notes: to use a plugin, you must define a custom GUC variable that specifies the name of the shared-object that implements the plugin. For example, to use the PL/pgSQL profiler (which is implement in $libdir/plugin_profiler.so), you would add the following to postgresql.conf
custom_variable_classes = 'plpgsql'
plpgsql.plugin = 'plugin_profiler'
The plpgsql.plugin variable is treated as an SUSET variable so you must be a superuser to change plugins.
Also, we define a helper function (in fmgr.c) named load_pl_plugin() that a language handler can use to load a plugin. The plugin requires the name of the GUC variable (plplgsql.plugin, pljava.plugin, plperl.pluhgN, etc.) and a pointer to a language-specific struct that the plugin fills in with a set of function pointers (presumably, the language handler will call those functions at appropriate points in time).
-- Korry
We are using this plugin mechanism to load the PL/pgSQL debugger on demand (the debugger is not part of this patch, the patch is just the infrastructure that we need to load various instrumentation plugins). We will also post some sample plugins (a PL/pgSQL profiler and a simple tracer), probably at the edb-debugger pgFoundry project site so you can see how to use the plugin mechanism.
A couple of notes: to use a plugin, you must define a custom GUC variable that specifies the name of the shared-object that implements the plugin. For example, to use the PL/pgSQL profiler (which is implement in $libdir/plugin_profiler.so), you would add the following to postgresql.conf
custom_variable_classes = 'plpgsql'
plpgsql.plugin = 'plugin_profiler'
The plpgsql.plugin variable is treated as an SUSET variable so you must be a superuser to change plugins.
Also, we define a helper function (in fmgr.c) named load_pl_plugin() that a language handler can use to load a plugin. The plugin requires the name of the GUC variable (plplgsql.plugin, pljava.plugin, plperl.pluhgN, etc.) and a pointer to a language-specific struct that the plugin fills in with a set of function pointers (presumably, the language handler will call those functions at appropriate points in time).
-- Korry
Attachment
"korryd@enterprisedb.com" <korryd@enterprisedb.com> writes:
> The attached patch adds support for loadable instrumentation plugins for
> procedural languages (as discussed at the anniversary summit). It also
> adds plugin support to the PL/pgSQL language handler.
In view of the other patch submitted to support init/fini functions for
shared libraries, I'm inclined to change this one to depend on that;
in particular it seems like we could eliminate the necessity for users
to specify the correct setup-function names. Thoughts?
regards, tom lane
In view of the other patch submitted to support init/fini functions for shared libraries, I'm inclined to change this one to depend on that; in particular it seems like we could eliminate the necessity for users to specify the correct setup-function names. Thoughts?
I think that would be great. Can you point me to the patch you're referring to? I can convert my patch if you prefer.
-- Korry
-- Korry Douglas korryd@enterprisedb.com EnterpriseDB http://www.enterprisedb.com |