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. :)
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 |
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 |