Intermittent regression test failure from index-only scans patch

Поиск
Список
Период
Сортировка
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?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: GiST for range types (was Re: Range Types - typo + NULL string constructor)
Следующее
От: Mark Mielke
Дата:
Сообщение: Re: [OT?] Time-zone database down [was: Re: timezone buglet?]