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




---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

> 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