Re: shared_preload_libraries support on Win32?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: korryd(at)enterprisedb(dot)com
Cc: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: shared_preload_libraries support on Win32?
Date: 2007-01-30 03:10:22
Message-ID: 23438.1170126622@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

<korryd(at)enterprisedb(dot)com> writes:
>> I see that Korry's patch doesn't do that, but I'm wondering why exactly.
>> In a Unix environment such libraries *would* be propagated into bgwriter
>> and every other postmaster child; is there a reason for the setup on
>> Windows to be different? In particular, what about autovacuum, which
>> ISTM should be as close to a standard backend as possible?

> I thought about that too... does autovacuum ever need to re-index? If
> so, it seems that it would need access to any index functions (for
> function-based indexes) that might reside in a shared_preload_library.

Any ordinary C-language function is not an issue, because its library
will get autoloaded upon use. AFAICS what we have to think about here
is instrumentation or debugging plugins that someone might wish to have
running in the postmaster's special children. Maybe there's no such
animal; I'm not sure. But in the Unix environment they'd be active in
those processes.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2007-01-30 03:31:51 Re: Modifying and solidifying contrib
Previous Message Tom Lane 2007-01-30 02:56:16 Re: [BUGS] Missing error message on missing ssl-key-files