Re: Reduced power consumption in autovacuum launcher process - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reduced power consumption in autovacuum launcher process
Date
Msg-id 2695.1310999701@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reduced power consumption in autovacuum launcher process  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Reduced power consumption in autovacuum launcher process
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jul 18, 2011 at 9:12 AM, Peter Geoghegan <peter@2ndquadrant.com> wrote:
>> There could perhaps be a very large "nap", as determined by
>> launcher_determine_sleep(), so that the total number of microseconds
>> passed to WaitLatch() would exceed the maximum long size that can be
>> safely represented on some or all platforms. On most 32-bit machines,
>> sizeof(long) == sizeof(int), which is just 4 bytes. (2^31) - 1 =
>> 2,147,483,647 microseconds = only about 35 minutes. There are corner
>> cases, such as if someone were to set autovacuum_naptime to something
>> silly.

> OK.  In that case, my feeling is "yes, you need to worry about that".
> I'm not sure exactly what the best solution is: we could either
> twiddle the WaitLatch interface some more, or restrict
> autovacuum_naptime to at most 30 minutes, or maybe there's some other
> option.

A wakeup once every half hour would surely not be an issue from a power
consumption standpoint.  However, I'm not sure I understand here: aren't
we trying to remove the timeouts completely?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Reduced power consumption in autovacuum launcher process
Next
From: Tom Lane
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Add temp_file_limit GUC parameter to constrain temporary file sp