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.
-- 
let name="cbbrowne" and tld="linuxdatabases.info" in name ^ "@" ^ tld;;
http://cbbrowne.com/info/slony.html
You know  how most packages say  "Open here". What is  the protocol if
the package says, "Open somewhere else"?