Re: [PATCHES] Autovacuum launcher doesn't notice death of postmaster immediately

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>
Cc: pgsql-hackers(at)postgresql(dot)org, pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCHES] Autovacuum launcher doesn't notice death of postmaster immediately
Date: 2007-06-13 17:29:11
Message-ID: 20070613172911.GC11499@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

ITAGAKI Takahiro wrote:
>
> Alvaro Herrera <alvherre(at)commandprompt(dot)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.

Attachment Content-Type Size
av-naptime-overflow.patch text/x-diff 6.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-06-13 17:39:05 tsearch_core patch: permissions and security issues
Previous Message Oleg Bartunov 2007-06-13 17:28:20 Re: Tom Lane's presentation on SERIALIZABLE etc?

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2007-06-13 18:05:23 Re: Controlling Load Distributed Checkpoints
Previous Message Andrew Dunstan 2007-06-13 15:53:03 Re: pipe chunks protocol