Steve Singer <ssinger at ca.afilias.info> writes:
> I see a few choices
>
> 1) We can have slon explicitly request a more reasonable thread stack 
> size before it creates threads (pthreads has API calls for this).  I'm 
> not 100% sure what the best value for this would be for all platforms 
> but slon tends to be pretty good about not storing large values on the stack
>
> 2) We can document this and tell sysadmins/DBA's that are concerned 
> about the slon memory footprint to use their OS's facilities (ie ulimit 
> -s before invoking slon) to adjust how much stack each thread.
>
> The argument for 1 is that the slony development team has a better sense 
> of how much stack memory slon threads take, and we might even discover 
> that different threads types of stack memory requirements (I doubt the 
> different slony thread types will very much in stack usage)
>
> The argument for 2 is that the OS is already providing facilities to 
> tune this and we should leave it tunable through those.
>
> Thoughts?

I agree with your reasonings for both 1 and 2...

I'll throw in another consideration that generally favours 2.

There are folks that run slon under Windows, which may have
substantially different behaviour.  I don't know how memory tuning works
there, and we might easily do a Unix-centric thing here that would break
Windows porting.
-- 
let name="cbbrowne" and tld="ca.afilias.info" in String.concat "@" [name;tld];;
Christopher Browne
"Bother,"  said Pooh,  "Eeyore, ready  two photon  torpedoes  and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"