On Tue, Aug 08, 2006, Tom Lane wrote:
> "Ralf S. Engelschall" <[EMAIL PROTECTED]> 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 a
"Ralf S. Engelschall" <[EMAIL PROTECTED]> 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_
Greg Stark <[EMAIL PROTECTED]> writes:
> Tom Lane <[EMAIL PROTECTED]> writes:
>> In any case, the PG_init proposal neither adds nor takes away ability
>> to do stuff immediately post-fork, so I think that's an orthogonal
>> consideration.
> So is the only question whether there's a need to do stuf
Tom Lane <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > So, for example if for someone wanted to
> > have a persistent Oracle connection they could not open it pre-fork at
> > library
> > load time but they might want to open it immediately after the fork rather
> > t
Gregory Stark <[EMAIL PROTECTED]> writes:
> So, for example if for someone wanted to
> have a persistent Oracle connection they could not open it pre-fork at library
> load time but they might want to open it immediately after the fork rather
> than when it's first used.
Uh ... why? Seems like al
Tom Lane <[EMAIL PROTECTED]> writes:
> No, my thought is that you'd rename PL/R's init function to PG_init, and
> then it'd get called automagically without needing to assume that the DBA
> remembers to specify it in preload_libraries. If there's a reason *not*
> to do that then it'd be a strike
On Thu, Aug 03, 2006, [EMAIL PROTECTED] wrote:
> On Wed, Aug 02, 2006 at 09:04:11PM +0200, Ralf S. Engelschall wrote:
> > PostgreSQL provides a way to load C extension modules with its internal
> > FMGR. Unfortunately there is no portable way for an extension module to
> > initialize (directly aft
Tom Lane wrote:
Joe Conway <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Also, if we do this we probably ought to remove the special-purpose
hack for preload_libraries to specify an init function --- it should
just happen by default. Any objections to simplifying that?
The original idea of us
Joe Conway <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Also, if we do this we probably ought to remove the special-purpose
>> hack for preload_libraries to specify an init function --- it should
>> just happen by default. Any objections to simplifying that?
> The original idea of using the i
Tom Lane wrote:
Also, if we do this we probably ought to remove the special-purpose
hack for preload_libraries to specify an init function --- it should
just happen by default. Any objections to simplifying that?
The original idea of using the init function with preload_libraries was
to eli
Tom Lane wrote:
"Ralf S. Engelschall" <[EMAIL PROTECTED]> 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 aft
David Fetter <[EMAIL PROTECTED]> writes:
> On Thu, Aug 03, 2006 at 05:30:48PM -0400, Tom Lane wrote:
>> 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?
> I'm not sure quite what you mean here, but
On Thu, Aug 03, 2006 at 05:30:48PM -0400, Tom Lane wrote:
> "Ralf S. Engelschall" <[EMAIL PROTECTED]> 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_
"Ralf S. Engelschall" <[EMAIL PROTECTED]> 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_
On Wed, Aug 02, 2006 at 09:04:11PM +0200, Ralf S. Engelschall wrote:
> PostgreSQL provides a way to load C extension modules with its internal
> FMGR. Unfortunately there is no portable way for an extension module to
> initialize (directly after the pg_dlopen() of the DSO) and to finish
> (directly
15 matches
Mail list logo
