I have just committed a change to HEAD (it's NOT 1.1.x material) that
fairly dramatically diminishes generation of pg_listener entries.

It does so by dropping the use of LISTEN/NOTIFY to handle event
confirmations.

Instead, the event loop rummages for confirmations each time events
are processed.

I'm not certain if this will lead to:
a) A 50% reduction in pg_listener "bloat", or

b) Quite a bit more, since each event needs to be confirmed (-> a dead
   tuple) for each node.

It means that, in principle, events get confirmed a little bit later.
It shouldn't be *much* later.

As a test to verify that WAIT FOR EVENT wasn't overly injured, I ran
the following bit of slonik over and over; it didn't wind up waiting
any appreciable period for confirmations.

=========================================================================
CLUSTER NAME = slony_regress1;
NODE 1 ADMIN CONNINFO = 'dbname=slonyregress1 host=localhost user=cbbrowne';
NODE 2 ADMIN CONNINFO = 'dbname=slonyregress2 host=localhost user=cbbrowne';
store path (server=1 , client=  2 ,  conninfo='dbname=slonyregress1 host=localhost user=cbbrowne port=5832');
WAIT FOR EVENT (ORIGIN = ALL, CONFIRMED = ALL, WAIT ON = 2);
=========================================================================

I'm thinking about a further revision that would essentially eliminate
use of pg_listener for the main event loop in local_listen.c.

We would poll based on sleeping for the -s value, increasing that
towards the -t value each time the poll finds nothing, dropping to 0
each time we find something (so that if things are behind, we don't
sleep when we should be working).

I'll have to think about it a bit more...
-- 
(reverse (concatenate 'string "ofni.sailifa.ac" "@" "enworbbc"))
<http://dba2.int.libertyrms.com/>
Christopher Browne
(416) 673-4124 (land)