Re: Autovacuum launcher doesn't notice death of postmaster immediately
От | Alvaro Herrera |
---|---|
Тема | Re: Autovacuum launcher doesn't notice death of postmaster immediately |
Дата | |
Msg-id | 20070613172911.GC11499@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: Autovacuum launcher doesn't notice death of postmaster immediately (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>) |
Список | pgsql-patches |
ITAGAKI Takahiro wrote: > > Alvaro Herrera <alvherre@commandprompt.com> 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. Ugh. How about this patch; this avoids the overflow issue altogether. I am not sure that this works on Win32 but it seems we are already using struct timeval elsewhere, so I don't see why it wouldn't work. > 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. Hmm, yes, the naptime should have an upper bound of INT_MAX/1000. It doesn't seem worth the trouble of changing those places, when we know that such a high value of naptime is uselessly high. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc.
Вложения
В списке pgsql-patches по дате отправления: