On Wed, 2008-05-28 at 11:36 -0400, Christopher Browne wrote:
> I am looking at the Slony-I CVS HEAD code with a view to eliminating
> the "abusive" uses of LISTEN/NOTIFY infrastructure, as that will be
> changing in 8.4.
> 
> In slonik.c, the function slonik_failed_node() uses a direct lookup on
> pg_listener in order to see if there is a "live" slon.
> 
> It uses the query:
>    select listenerpid from pg_catalog.pg_listener 
>    where relname = '_[Cluster]_Restart';
> 
> I don't see another _direct_ way to get at PIDs.  The closest that I
> can see is to replace this query with something like:
> 
>    select nl_backendpid from sl_nodelock 
>     where nl_nodeid = @NAMESPACE at .getLocalNodeId(''_ at CLUSTERNAME@'') and
>     exists (select * from pg_stat_activity where procpid = nl_backendpid);
> 
> That *does* plug in perfectly nicely. 
> 
> Unfortunately, pg_stat_activity pulls the PIDs from the stats
> collector, so that there is a delay in changes being reported.  (And I
> have seen situations where the stats collector got "blown," in which
> case, this wouldn't report anything even *nearly* correct.)
> 
> Is there some more direct way to get at PIDs?  A search of
> pg_attribute and pg_proc for '%pid%' doesn't show up anything.

Seems like the best way is to encapsulate this. Work out the API you
would like, then we can take that to pgsql-hackers. Once we agree the
API we can write a function to do that for 8.3 and below and put the
function into Postgres backend for 8.4 and later. That way any further
changes to LISTEN/NOTIFY will be able to change that also, so you are
future-proofed around the changes.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support