Re: why local_preload_libraries does require a separate directory ?
От | Tomas Vondra |
---|---|
Тема | Re: why local_preload_libraries does require a separate directory ? |
Дата | |
Msg-id | 4EDD52F0.8000508@fuzzy.cz обсуждение исходный текст |
Ответ на | Re: why local_preload_libraries does require a separate directory ? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 5.12.2011 00:06, Tom Lane wrote: > Tomas Vondra <tv@fuzzy.cz> writes: >> On 4.12.2011 22:16, Tom Lane wrote: >>> Um ... why would you design it like that? > >> 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. > > That's an unbelievably ugly, and dangerous, kluge. All you need is one > backend not loading the second library (and remember, > local_preload_libraries is user-settable) and you've just locked up the > system. > > Why are you using pg_stat_activity for this anyway? Searching the > ProcArray seems much safer ... see CountDBBackends for an example. Thanks, reading ProcArray works fine, although the ProcArrayStruct is private to procarray.c so I had to create a local copy. That sounds a bit too fragile I guess - whenever it changes, the extension will break without a warning. Tomas
В списке pgsql-hackers по дате отправления: