Re: [PATCHES] PL instrumentation plugin and Rendezvous variable support - version 2

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [PATCHES] PL instrumentation plugin and Rendezvous variable support - version 2
Date: 2006-08-15 19:08:09
Message-ID: 19148.1155668889@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

"korryd(at)enterprisedb(dot)com" <korryd(at)enterprisedb(dot)com> writes:
> This is an updated version of the PL instrumentation plugin patch that I
> submitted on July-28. The new version re-implements the plugin loader
> code to use "rendezvous variables" as suggested by Tom Lane (thanks Tom,
> very elegant design).

Applied with a few small changes --- I renamed the GUC variables after a
suggestion by Simon Riggs, and fixed things so that
backend_load_libraries could actually do something useful (you had it as
PGC_POSTMASTER, making it effectively no more flexible than the existing
preload_libraries list).

The only change that will directly impact your code is that I thought
it'd be better to provide plpgsql_exec_error_callback and
exec_assign_expr as separate fields instead of arguments to func_setup,
viz

if (*plugin_ptr)
{
(*plugin_ptr)->error_callback = plpgsql_exec_error_callback;
(*plugin_ptr)->assign_expr = exec_assign_expr;

if ((*plugin_ptr)->func_setup)
((*plugin_ptr)->func_setup)(estate, func);
}

I'm not totally wedded to this if you don't like it, but my thought was
that passing these as arguments to func_setup would mean a lot of pain
anytime we wanted to change the set of function pointers provided:
every plugin would need textual changes whether it actually used these
functions or not.

> I have not implemented any support for unloading shared libraries. Once
> we've finalized the design for rendezvous variables, I'll submit a
> separate documentation patch.

I added docs for the GUC variables but didn't do more than that. I
think the code comments are probably sufficient as far as rendezvous
variables and PLpgSQL_plugin go ... did you have something else in mind?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2006-08-15 19:22:19 Re: [PATCHES] Custom variable class segmentation fault
Previous Message Jim C. Nasby 2006-08-15 18:55:22 Re: [HACKERS] Forcing current WAL file to be archived

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-08-15 19:22:19 Re: [PATCHES] Custom variable class segmentation fault
Previous Message Jim C. Nasby 2006-08-15 18:55:22 Re: [HACKERS] Forcing current WAL file to be archived