Skip site navigation (1) Skip section navigation (2)

Re: Bug in pg_autovacuum ?

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 (view raw or flat)
Thread:
Lists: pgsql-bugspgsql-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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-01-18 03:22:51
Subject: Re: User Defined Functions/AM's inherently slow?
Previous:From: Eric RidgeDate: 2004-01-18 02:25:43
Subject: User Defined Functions/AM's inherently slow?

pgsql-bugs by date

Next:From: PostgreSQL Bugs ListDate: 2004-01-18 12:41:56
Subject: BUG #1054: inefficient compression of doco html files
Previous:From: Cott LangDate: 2004-01-17 23:22:45
Subject: Bug in pg_autovacuum ?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group