Re: [BUGS] Patch to allow C extension modules to initialize/finish

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: rse(at)engelschall(dot)com
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUGS] Patch to allow C extension modules to initialize/finish
Date: 2006-08-03 21:30:48
Message-ID: 26529.1154640648@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

"Ralf S. Engelschall" <rse(at)engelschall(dot)com> writes:
> Hence I propose the patch below (applies to PostgreSQL 8.1.4) which
> mimics the dlopen(3) and dlclose(3) behaviour of some Unix platforms
> and resolves and calls _PG_init and _PG_fini functions of an extension
> module right after/before the pg_dlopen/pg_dlclose calls in the FMGR.

This seems like a reasonably good idea, and we have got uses for at
least the "init" case in most or all of our PLs. It's nominally too
late for 8.2 feature freeze, but I said just a couple days ago that
we shouldn't take a very hard line on that. Does anyone object to
considering this for 8.2?

One question I have is whether it really works as expected in all cases.
In particular what if the library is "preloaded" into the postmaster?
Both plpgsql and plperl seem to think they might need to make a
distinction between things to do at library load time and things to do
per-backend ... and yet, neither of them *actually* have anything they
need to do per-backend.

Also, what about Windows? I assume that DSOs don't remain attached
across the pseudo-fork/exec, will that mess anything up?

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David Fetter 2006-08-03 21:37:12 Re: [BUGS] Patch to allow C extension modules to initialize/finish
Previous Message IvankoB 2006-08-03 20:23:59 BUG #2562: In rules: recalculation of input expression on each access

Browse pgsql-hackers by date

  From Date Subject
Next Message Ron Mayer 2006-08-03 21:31:50 Re: O_NOATIME
Previous Message Tom Lane 2006-08-03 21:14:36 Re: tg_trigtuple/tg_newtuple settings in AFTER triggers