Alvaro Herrera <[EMAIL PROTECTED]> wrote: > > No, I meant a "while (sleep 1(or 10) and counter < longtime) check for > > exit" instead of "sleep longtime". > > Ah; yes, what I was proposing (or thought about proposing, not sure if I > posted it or not) was putting a upper limit of 10 seconds in the sleep > (bgwriter sleeps 10 seconds if configured to not do anything). Though > 10 seconds may seem like an eternity for systems like the ones Peter was > talking about, where there is a script trying to restart the server as > soon as the postmaster dies.
Here is a patch for split-sleep of autovacuum_naptime. There are some other issues in CVS HEAD; We use the calculation {autovacuum_naptime * 1000000} in launcher_determine_sleep(). The result will be corrupted if we set autovacuum_naptime to >2147. In another place, we use {autovacuum_naptime * 1000}, so we should set the upper bound to INT_MAX/1000 instead of INT_MAX. Incidentally, we've already had the same protections for log_min_duration_statement and log_autovacuum. I hope this patch could fix those large-autovacuum_naptime problems. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center
autovacuum_naptime_overflow.patch
Description: Binary data
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster