Alvaro Herrera wrote: > Stefan Kaltenbrunner wrote: > > yeah - looks like it's the autovacuum change - snake is now passing the > > numeric-test but still fails the stats one ... > > Interesting -- both yak and snake are failing in a very similar way. > I'll investigate it tomorrow if no one beats me to it.
All our Windows buildfarm machines are failing. AFAICT, the first failure was on Yak, http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=yak&dt=2007-01-16%2021:55:20 and the last successful run just before that seems to come from Snake, http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snake&dt=2007-01-16%2014:30:00 The only changes that went in in that period are the patch that enabled autovacuum by default, an information_schema fix and a TODO file change. The only that could cause this problem seems to be the autovacuum enable bit. The failures are all exactly alike: *** ./expected/stats.out Thu Jan 18 08:48:12 2007 --- ./results/stats.out Thu Jan 18 09:02:53 2007 *************** *** 51,57 **** WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! t | t | t | t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, --- 51,57 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- ! f | f | f | f (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, *************** *** 60,66 **** WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- ! t | t (1 row) -- End of Stats Test --- 60,66 ---- WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- ! f | f (1 row) -- End of Stats Test The full failing queries are these: -- check effects SELECT st.seq_scan >= pr.seq_scan + 1, st.seq_tup_read >= pr.seq_tup_read + cl.reltuples, st.idx_scan >= pr.idx_scan + 1, st.idx_tup_fetch >= pr.idx_tup_fetch + 1 FROM pg_stat_user_tables AS st, pg_class AS cl, prevstats AS pr WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? | ?column? | ?column? ----------+----------+----------+---------- t | t | t | t (1 row) SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages, st.idx_blks_read + st.idx_blks_hit >= pr.idx_blks + 1 FROM pg_statio_user_tables AS st, pg_class AS cl, prevstats AS pr WHERE st.relname='tenk2' AND cl.relname='tenk2'; ?column? | ?column? ----------+---------- t | t (1 row) The six booleans are false on Windows. What could be the reason for this change? The only thing that occurs to me is that autovacuum is firing just when running that test, it processes that table and increments the counters before the final SQL is run. Now, if some Windows-enabled person could step forward so that we can suggest some tests to run, that would be great. Perhaps the solution to the problem is to relax the conditions a little, so that two scans are accepted on that table instead of only one; but it would be good to confirm whether the stat system is really working and it's really still counting stuff as it's supposed to do. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
