Re: [BUGS] Bug in pg_autovacuum ? - Mailing list pgsql-hackers

From Matthew T. O'Connor
Subject Re: [BUGS] Bug in pg_autovacuum ?
Date
Msg-id 1076540239.29819.0.camel@zedora.zeut.net
Whole thread Raw
In response to Re: [BUGS] Bug in pg_autovacuum ?  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: [BUGS] Bug in pg_autovacuum ?  (Cott Lang <cott@internetstaff.com>)
List pgsql-hackers
Yeah, I'll take a look at it and submit a patch.  Sorry I didn't see it
sooner, but I don't read the bugs mailing list.

On Wed, 2004-02-11 at 17:29, Bruce Momjian wrote:
> Would someone review these problems and submit a patch?  Thanks.
> 
> ---------------------------------------------------------------------------
> 
> Tom Lane wrote:
> > Cott Lang <cott@internetstaff.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
> > 
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Don't 'kill -9' the postmaster
> > 



pgsql-hackers by date:

Previous
From: hong.ge@yale.edu
Date:
Subject: Re: How can I have 2 completely seperated databases in PostgreSQL?
Next
From: "scott.marlowe"
Date:
Subject: Re: How can I have 2 completely seperated databases in