Bug in pg_autovacuum ?

From: Cott Lang <cott(at)internetstaff(dot)com>
To: PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org>
Subject: Bug in pg_autovacuum ?
Date: 2004-01-17 23:22:45
Message-ID: 1074381764.2237.81.camel@blackbox
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

I'm having a problem with pg_autovacuum against both 7.3.2 and 7.4.1 on
Redhat 9 and Fedora Core 1. I'm using pg_autovacuum from 7.4.1,
everything comes from the postgresql.org RPMs.

If the number of tuples is sufficiently high, pg reports 'reltuples'
back in TABLE_STATS_QUERY in scientific notation instead of an integer.

Example:

4.35351e+06 instead of 4353514

pg_autovacuum then uses atoi() to reach the incorrect conclusion that
there are 4 tuples. Obviously, if that table gets more than a couple of
updates, it gets vacuumed a bit too often. :)

Changing from atoi() to atof() solves the problem completely.

new_tbl->reltuples =
atof(PQgetvalue(res, row, PQfnumber(res, "reltuples")));

new_tbl->relpages =
atof(PQgetvalue(res, row, PQfnumber(res, "relpages")));

I'm not sure how I can be the only person running into this. :)

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2004-01-18 03:18:36 Re: Bug in pg_autovacuum ?
Previous Message Tom Lane 2004-01-17 17:26:16 Re: BUG #1053: Configuration should be in /etc/postgres

Browse pgsql-hackers by date

  From Date Subject
Next Message Eric Ridge 2004-01-18 02:25:43 User Defined Functions/AM's inherently slow?
Previous Message Tom Lane 2004-01-17 17:26:16 Re: BUG #1053: Configuration should be in /etc/postgres