(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
[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
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
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 be loaded
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 not
[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_libraries is
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 the copy
[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 doesn't seem like
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 doesn't
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
[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, what about
11 matches
Mail list logo
