Skip site navigation (1) Skip section navigation (2)

Re: why local_preload_libraries does require a separate directory ?

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: why local_preload_libraries does require a separate directory ?
Date: 2011-12-05 23:25:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 5.12.2011 00:06, Tom Lane wrote:
> Tomas Vondra <tv(at)fuzzy(dot)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.


In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2011-12-05 23:27:29
Subject: Re: [PATCH] PostgreSQL fails to build with 32bit MinGW-w64
Previous:From: Marti RaudseppDate: 2011-12-05 23:05:42
Subject: Re: [PATCH] Caching for stable expressions with constant arguments v3

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group