Re: [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Lionel Bouton <lionel-subscription(at)bouton(dot)name>
Cc: PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [BUGS] BUG #1588: pg_autovacuum sleep parameter overflow
Date: 2005-05-11 14:52:34
Message-ID: 200505111452.j4BEqYB26325@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-patches

Lionel Bouton wrote:
>
> The following bug has been logged online:
>
> Bug reference: 1588
> Logged by: Lionel Bouton
> Email address: lionel-subscription(at)bouton(dot)name
> PostgreSQL version: 8.0.1
> Operating system: Linux 2.6, glibc 2.3.4
> Description: pg_autovacuum sleep parameter overflow
> Details:
>
> pg_autovacuum doesn't sleep when the -s parameter is set above 2147
> (PostgreSQL then is under constant stress), seems like a 32-bit signed
> integer overflow (the time in s then gets past 2^31-1) somewhere.
>
> This worked with 7.4.6 (at least with -s 3600).

Yes, this is a bug. Right now, pg_autovacuum uses pg_usleep(), which
accepts a 'long' value representing the number of microseconds to sleep.
Because long is 32-bits on many platforms, it overflows around 2 billion
microseconds, which is 2147 seconds. The comment in pg_usleep()
verifies it:

* On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.

Here is a proposed patch that will fix it. There is no reason to use
pg_usleep in pg_autovacuum in this area, so we just use sleep(). We
don't need micro-second accuracy, and we don't need Win32 to handle
signals that arrive during the sleep.

However, I am now wondering if we should change pg_usleep() to take a
double rather than long. This would avoid such problems in the future
in other places in our code.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

Attachment Content-Type Size
unknown_filename text/plain 1.0 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Beckstette 2005-05-11 14:59:43 Missing tables in postgresql 7.2.4
Previous Message Vincent Vanwynsberghe 2005-05-11 13:04:42 Re: Bug Report with Postgres 7.4 on AIX 5.3

Browse pgsql-patches by date

  From Date Subject
Next Message Andrew Dunstan 2005-05-11 14:55:08 plperl and pltcl installcheck targets
Previous Message a_ogawa 2005-05-11 14:03:51 AllocSetReset improvement