Hannu Krosing wrote:

>On K, 2005-06-29 at 11:11 -0400, Christopher Browne wrote:
>  
>
>>With the release of 1.1.0, this now frees us to start looking at what
>>should start going into version 1.2.  A number of activities have been
>>awaiting this:
>>
>>1.  Known enhancements where concrete changes are forthcoming:
>> a) Rotating between sl_log_1 and sl_log_2
>> b) Improving performance of COPY_SET by dropping/recreating indices
>> c) Win32 support
>> d) Major revision to test suite
>>    
>>
>
> e) enable slon to run in polling mode on heavy-use scenarios to avoid
>needless LISTEN/NOTIFY overhead and also not to grow a huge pg_listener
>when there are long transactions.
>  
>
All of the #1 items are ones for which a clear strategy is available,
where either a patch already exists, or someone has at least prototyped
the change, and has verified feasibility.

If you have a patch, or something near to one, then this can fall into
category #1.

If not, then it has to stay at the "wishful" stage for now.

I'm not at all sure that changing to some sort of "polling mode" would
address anything anyways.  The problems with pg_listener growth are...

1.  A lot of events are generated and deleted.  Changing the polling
interval won't change this; it merely shifts the lifecycle.

2.  The problem tends to be on the provider node; the only way I can see
to avoid the problem of dead tuples is if, during the "long running
transaction," we altogether *turn off* replication, which introduces a
different risk, namely that subscribers would have to wait to start
replicating until after that transaction, which probably doesn't fit
with the notion of subscribers being kept pretty well up to date.

Or perhaps I am misunderstanding the change you have in mind.