Re: Loading the PL/pgSQL debugger (and other plugins)

On Wed, Jul 19, 2006 at 01:35:16PM -0400, Tom Lane wrote:
> > 1) I think the most straightforward way to load an instrumentation
> > plugin is to define a new custom GUC variable (using the
> > custom_variable_classes mechanism).
>
> This seems a bit messy and special-purpose. I see no good reason to tie
> it to plpgsql; we'll just need another one for every other language.
> IMHO what we want is something with similar properties to preload_libraries,
> but processed on a per-backend basis instead of once at postmaster start.
> (You could almost just tell people to select the plugin they want by
> LOADing it, but that is hard to use if you're trying to debug a
> non-interactive application. A GUC variable can be set for an app
> without much cooperation from the app.)
<snip>
> We should also think about a deregistration function. This would allow
> you to turn debugging on and off within an interactive session. The
> GUC variable is really only for coercing non-interactive applications
> into being debuggable --- I don't see it as being important for
> interactive debugging, as compared to just "select plugin_init();" ...

This isn't the only example of where it would be handy to be able to
tell a certain backend or group of backends to do something, so you
could gain more insight into what some application is doing. Turning on
query logging is another example that comes to mind.

Is there some way we could allow one backend to tell another backend to
change certain aspects of its behavior? One idea is to have a function
that can send commands to another backend via some form of IPC. That
backend would then execute the commands the next time it would normally
accept commands from it's client connection. Of course this creates a
pretty big foot-gun, so we might want to greatly restrict what kind of
commands could be executed this way.

Another possibility would be allowing users to specify certain GUC
settings for backends that match certain criteria when they're spawned,
such as what IP the client is connecting from, or what user it's
authenticating as.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461