On 3.12.2011 18:53, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
>> why the libraries loaded using local_preload_libraries need to be placed
>> in a different subdirectory than libraries loaded using
> Security: it lets the DBA constrain which libraries are loadable this way.
But local_preload_libraries can be set only in postgresql.conf, right?
As this file is maintainted by the DBA, so how does this improve the
The problem I'm trying to solve right now is that I do have an extension
that needs to install two .so libraries - one loaded using
shared_preload_libraries, one loaded using local_preload_libraries.
The "make install" puts both files into $libdir, so I have to copy it to
the right directory.
>> I do understand that leaving the users to load whatever libraries they
>> want is a bad idea, but when the library is loaded from postgresql.conf
>> it should be safe.
> We don't have a mechanism that would allow different limitations to be
> placed on a GUC variable depending on where the value came from.
> To do what you're proposing would require restricting
> local_preload_libraries to be superuser-only, which would be a net
> decrease in functionality.
Now I'm really confused. AFAIK local_preload_libraries can be set only
from postgresql.conf, not by a user. So the check could be quite simple
- is the backend already started? No: don't check the path. Yes: check
that the path starts with '$libdir/plugin'.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2011-12-03 18:36:04|
|Subject: Re: Inlining comparators as a performance optimisation |
|Previous:||From: Andres Freund||Date: 2011-12-03 18:17:14|
|Subject: Re: Command Triggers|