From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Cott Lang <cott(at)internetstaff(dot)com> |
Cc: | PostgreSQL Bugs List <pgsql-bugs(at)postgresql(dot)org> |
Subject: | Re: Bug in pg_autovacuum ? |
Date: | 2004-01-18 03:18:36 |
Message-ID: | 1542.1074395916@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
Cott Lang <cott(at)internetstaff(dot)com> writes:
> If the number of tuples is sufficiently high, pg reports 'reltuples'
> back in TABLE_STATS_QUERY in scientific notation instead of an integer.
Right, because that column is actually a float4.
> 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 should think this would break in different ways once reltuples exceeds
INT_MAX. A full fix would require changing new_tbl->reltuples to be
float or double, and coping with any downstream changes that implies.
Also, relpages *is* an integer, though it's best interpreted as an
unsigned one. (Ditto for relid.) Looks like this code is 0-for-3 on
getting the datatypes right :-(
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | PostgreSQL Bugs List | 2004-01-18 12:41:56 | BUG #1054: inefficient compression of doco html files |
Previous Message | Cott Lang | 2004-01-17 23:22:45 | Bug in pg_autovacuum ? |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2004-01-18 03:22:51 | Re: User Defined Functions/AM's inherently slow? |
Previous Message | Eric Ridge | 2004-01-18 02:25:43 | User Defined Functions/AM's inherently slow? |