2011/10/8 Tom Lane <tgl@sss.pgh.pa.us>:
> I notice that several members of the buildfarm have been consistently
> showing the same regression test failure since the index-only scans
> patch went in:
>
> *** /home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/expected/stats.out Sat Oct 8 03:20:05 2011
> --- /home/pgbuildfarm/workdir/HEAD/pgsql.27150/src/test/regress/results/stats.out Sat Oct 8 12:30:55 2011
> ***************
> *** 94,100 ****
> 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,
> --- 94,100 ----
> WHERE st.relname='tenk2' AND cl.relname='tenk2';
> ?column? | ?column? | ?column? | ?column?
> ----------+----------+----------+----------
> ! t | t | t | f
> (1 row)
>
> SELECT st.heap_blks_read + st.heap_blks_hit >= pr.heap_blks + cl.relpages,
>
>
> The diff indicates that the idx_scan count advanced but idx_tup_fetch
> did not, which is not so surprising here because tenk2 hasn't been
> modified in some time. If the autovacuum daemon managed to mark it
> all-visible before the stats test runs, then an index-only scan will
> happen, and bingo, no idx_tup_fetch increment (because indeed no heap
> tuple was fetched).
>
> I'm inclined to fix this by changing the test to examine idx_tup_read
> not idx_tup_fetch. Alternatively, we could have the test force
> enable_indexonlyscan off. Thoughts?
No preferences, but is it interesting to add a "vacuum freeze"
somewhere and check expected result after index-only scan ? (for both
idx_tup_read and idx_tup_fetch)
>
> regards, tom lane
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation