On Mon, Jul 18, 2011 at 10:35 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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?
Well, in the case of the AV launcher, the issue is that the main loop
is timed by definition, cf. autovacuum_naptime, and the WaitLatch()
interface is apparently designed so that we can't sleep longer than 35
minutes. We can avoid waking every second simply to check whether the
postmaster has died, but waking up every autovacuum_naptime seems de
rigeur barring a major redesign of the mechanism.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company