Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
Not sure if anyone reported to you but we fixed these in current CVS and will have the fix in 7.4.3. --- Cott Lang wrote: On Wed, 2004-02-11 at 16:25, Bruce Momjian wrote: Sure, shoot them over to hackers or patches. The pg_autovacuum author is looking into this. Here they are. They've worked well for me, but someone wiser in the ways of C should certainly look them over. :) [ Attachment, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
Would someone review these problems and submit a patch? Thanks. --- Tom Lane wrote: Cott Lang [EMAIL PROTECTED] 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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
I have my original changes + Tom's recommended changes applied to 7.4.1 if you're interested. On Wed, 2004-02-11 at 15:57, Matthew T. O'Connor wrote: 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 [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
Cott Lang wrote: I have my original changes + Tom's recommended changes applied to 7.4.1 if you're interested. Sure, shoot them over to hackers or patches. The pg_autovacuum author is looking into this. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [BUGS] Bug in pg_autovacuum ?
On Wed, 2004-02-11 at 16:25, Bruce Momjian wrote:
Sure, shoot them over to hackers or patches. The pg_autovacuum author
is looking into this.
Here they are. They've worked well for me, but someone wiser in the ways
of C should certainly look them over. :)
? autovac.patch
? pg_autovacuum
Index: pg_autovacuum.c
===
RCS file: /projects/cvsroot/pgsql-server/contrib/pg_autovacuum/pg_autovacuum.c,v
retrieving revision 1.13
diff -u -r1.13 pg_autovacuum.c
--- pg_autovacuum.c 8 Dec 2003 21:54:00 - 1.13
+++ pg_autovacuum.c 12 Feb 2004 00:25:57 -
@@ -118,7 +118,7 @@
new_tbl-curr_vacuum_count = new_tbl-CountAtLastVacuum;
new_tbl-relid = atoi(PQgetvalue(res, row, PQfnumber(res, oid)));
- new_tbl-reltuples = atoi(PQgetvalue(res, row, PQfnumber(res, reltuples)));
+ new_tbl-reltuples = atof(PQgetvalue(res, row, PQfnumber(res, reltuples)));
new_tbl-relpages = atoi(PQgetvalue(res, row, PQfnumber(res, relpages)));
if (strcmp(t, PQgetvalue(res, row, PQfnumber(res, relisshared
@@ -159,7 +159,7 @@
if (res != NULL)
{
tbl-reltuples =
-atoi(PQgetvalue(res, 0, PQfnumber(res, reltuples)));
+atof(PQgetvalue(res, 0, PQfnumber(res, reltuples)));
tbl-relpages = atoi(PQgetvalue(res, 0, PQfnumber(res, relpages)));
/*
@@ -363,7 +363,7 @@
log_entry(logbuffer);
sprintf(logbuffer, relid: %i; relisshared: %i, tbl-relid, tbl-relisshared);
log_entry(logbuffer);
- sprintf(logbuffer, reltuples: %i; relpages: %i, tbl-reltuples, tbl-relpages);
+ sprintf(logbuffer, reltuples: %.0f; relpages: %i, tbl-reltuples, tbl-relpages);
log_entry(logbuffer);
sprintf(logbuffer, curr_analyze_count: %li; cur_delete_count: %li,
tbl-curr_analyze_count, tbl-curr_vacuum_count);
Index: pg_autovacuum.h
===
RCS file: /projects/cvsroot/pgsql-server/contrib/pg_autovacuum/pg_autovacuum.h,v
retrieving revision 1.8
diff -u -r1.8 pg_autovacuum.h
--- pg_autovacuum.h 1 Dec 2003 23:19:33 - 1.8
+++ pg_autovacuum.h 12 Feb 2004 00:25:57 -
@@ -84,10 +84,12 @@
{
char *schema_name,
*table_name;
- int relid,
-reltuples,
-relisshared,
-relpages;
+ unsigned int relid,
+ relpages;
+
+ int relisshared;
+ double reltuples;
+
long analyze_threshold,
vacuum_threshold;
long CountAtLastAnalyze; /* equal to: inserts + updates as
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
