<[EMAIL PROTECTED]> 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, wha
> >> You're right - we need the copy in the postmaster (to setup shared
> >> memory and LW locks), and we need them in the backends too.
>
> > Just make sure you don't load the libraries in bgwriter et al ...
>
> I see that Korry's patch doesn't do that, but I'm wondering why exactly.
> In a Unix
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>> You're right - we need the copy in the postmaster (to setup shared
>> memory and LW locks), and we need them in the backends too.
> Just make sure you don't load the libraries in bgwriter et al ...
I see that Korry's patch d
[EMAIL PROTECTED] wrote:
> > > And, shared_preload_libraries is processed (in the postmaster) before
> > > the shared-memory segment is created, so a shared_preload_library can
> > > call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
> > > local_preload_library cannot.
> >
> > That doe
> > And, shared_preload_libraries is processed (in the postmaster) before
> > the shared-memory segment is created, so a shared_preload_library can
> > call RequestAddinShmemSpace() and RequestAddinLWLocks(), but a
> > local_preload_library cannot.
>
> That doesn't seem like an issue though, since
<[EMAIL PROTECTED]> writes:
>> But in the new world of plugins there may be functional reasons for
>> wanting libraries to be loaded into backends --- and
>> shared_preload_libraries is not isomorphic to local_preload_libraries.
>> The permissions situation is different.
> And, shared_preload_libr
> Actually ... I take that back. I was thinking of the original purpose
> of preload_libraries, which was strictly performance optimization.
> But in the new world of plugins there may be functional reasons for
> wanting libraries to be loaded into backends --- and
> shared_preload_libraries is no
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I don't entirely see the point. The value of shared_preload_libraries
>> is to avoid paying per-process overhead to load the libraries, and that
>> benefit is already lost in a fork/exec world. Might as well just let
>> the libraries
Tom Lane wrote:
<[EMAIL PROTECTED]> writes:
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Well, yeah, because it's a fork/exec on that platform.
Should we just call process_shared_preload_librarie
<[EMAIL PROTECTED]> writes:
> It appears that the libraries listed in shared_preload_libraries will
> *not* be inherited by spawned backends on Win32 platforms.
Well, yeah, because it's a fork/exec on that platform.
> Should we just call process_shared_preload_libraries() after calling
> read_non
(working on the PL debugger...)
It appears that the libraries listed in shared_preload_libraries will
*not* be inherited by spawned backends on Win32 platforms.
Do we have to do something special to make that work?
Using ProcessExplorer (from sysinternals.com), I can see that my plugins
are loa
11 matches
Mail list logo
