If this happens just once or twice, then I wouldn't worry.

We start by allocating 100 elements to track the monitoring activities, and
basically two things tend to happen:

a) Each thread is pushing elements on the stack indicating what the thread
is up to;

b) Periodically, the monitoring thread pulls everything off the stack and
updates the table sl_components to stow in the database what the thread is
up to.

If, for some reason, threads are throwing things onto the stack much faster
than the monitoring thread pulls them off, then the stack will need to get
resized.  That's a bit unusual, hence the warning message that you are
seeing.

Note that each time the stack runs out, the function monitor_state()
doubles its size, which should very quickly make it implausible that you'd
need more space unless the monitoring code has gone pretty crazy.

When we were testing the facility, we set the initial stack size to
something small (~10), so as to be sure that the "need to double the size"
logic worked OK.  It's a wee bit surprising that you'd have >>100
monitoring events stacked up for processing.

Have you got a cluster with a lot of nodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.slony.info/pipermail/slony1-general/attachments/20130820/00a05de9/attachment.htm