Windows buildfarm failures - Mailing list pgsql-hackers

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
ASprWHERE 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 prWHERE 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