Thanks, I'll take a look - haven't used the .conf files before. Sounds
easier than an environment variable, too! 

> -----Original Message-----
> From: Christopher Browne [mailto:cbbrowne at ca.afilias.info] 
> Sent: Monday, April 24, 2006 10:51 AM
> To: David Parker
> Cc: slony1-general at gborg.postgresql.org
> Subject: Re: [Slony1-general] wait interval in slon cleanup thread
> 
> David Parker wrote:
> > 1.1.5-RC2
> >  
> > We have a fairly high transaction rate on database in which we have 
> > slony installed. In some of our load-testing we are ending up with 
> > ~400K records in the sl_log_1 table within the default 
> > SLON_CLEANUP_SLEEP. Since we have to limit disk usage as much as 
> > possible for this particular database, we would like to reduce the 
> > cleanup interval to limit the growth of that table, but I don't see 
> > any way to configure this.
> >  
> > My current plan is just to use an environment variable, and 
> hack our 
> > copy of the code to be aware of it. Is there an already-supported, 
> > easier way to configure this that I have just missed?
> >  
> > Also, I'd like to hear any caveats/warnings about lower 
> bound limits 
> > for this value, e.g. in which situations the possibility of 
> deadlock 
> > somewhere arises, etc.
> >  
> > Thanks in advance.
> Rather than using an environment variable, I'd suggest 
> turning this into one of the internal slon options.
> 
> That would involve:
> 
> 1.  setting up a variable name, probably defined in either 
> slon.c or maybe directly in cleanup-thread.c
> 
> 2.  adding an entry to ConfigureNamesInt in conf-options.h
> 
> 3.  Using the variable in cleanup-thread.c
> 
> 4.  Documentation changes :-)
> 
> That way this would be easy to put into CVS HEAD and add in 
> for others'
> use.  (And you could configure it in slon .conf files, and such...)
> 
> As far as lower bound goes, I don't see too much problem 
> there.  The value is used to determine how long the cleanup 
> thread sleeps between invocations.  The shortest that could 
> *possibly* fall to is zero, in which case it would run continually.
>