Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

pgsql-hackers by date

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

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group