Re: why local_preload_libraries does require a separate directory ?
От | Tomas Vondra |
---|---|
Тема | Re: why local_preload_libraries does require a separate directory ? |
Дата | |
Msg-id | 4EDC0D54.1020501@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. Yes, but I wasn't aware of that - I thought local_preload_libraries is defined in postgresql.conf so it seemed fine (yes, it was ugly but it did not seem that dangerous). > Why are you using pg_stat_activity for this anyway? Searching the > ProcArray seems much safer ... see CountDBBackends for an example. Because I've never user ProcArray before, but I use pg_stat_activity quite frequently, so it seemed very natural. Thanks for pointing to ProcArray/CountDBBackends, I'll see how to use that. Tomas
В списке pgsql-hackers по дате отправления: