Re: why local_preload_libraries does require a separate directory ?
От | Tomas Vondra |
---|---|
Тема | Re: why local_preload_libraries does require a separate directory ? |
Дата | |
Msg-id | 4EDBEC84.2030809@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: why local_preload_libraries does require a separate directory ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: why local_preload_libraries does require a separate directory ?
|
Список | pgsql-hackers |
On 4.12.2011 22:16, Tom Lane wrote: > Tomas Vondra <tv@fuzzy.cz> writes: >> On 3.12.2011 18:53, Tom Lane wrote: >>> Security: it lets the DBA constrain which libraries are loadable this way. > >> But local_preload_libraries can be set only in postgresql.conf, right? > > No. It's PGC_BACKEND, which means it can be set at connection start by > a client (eg, via PGOPTIONS). > >> 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. > > Um ... why would you design it like that? Well, the purpose of the extension is to limit number of connections by db/user/IP. It's using pg_stat_activity and auth hook, and the rules are loaded from a file into a shared memory segment. So I need to: 1) allocate memory to keep the rules (so it has to be loaded using shared_preload_libraries) 2) check the rules (this is done in auth hook) using pg_stat_activity The backends are added to pg_stat_activity after the auth hook finishes, which means possible race conditions (backends executed at about the same time don't see each other in pg_stat_activity). So I use an exclusive lock that's acquired before reading pg_stat_activity and released after the pg_stat_activity is updated. That's the only thing the library loaded using local_preload_libraries does - it releases the lock. Tomas
В списке pgsql-hackers по дате отправления: