Re: [HACKERS] Bug? relpages, reltuples resets to zero

> Hi,
>
> there seems to be a problem with the relation statistics in
> pg_class. Could someone explain why this happens?
>
> doc=> vacuum;
> VACUUM
> doc=> select relname, relpages, reltuples from pg_class
> doc-> where relname = 'doc_wordref';

> doc=> select relname, relpages, reltuples from pg_class
> doc-> where relname = 'doc_wordref';
> relname |relpages|reltuples
> -----------+--------+---------
> doc_wordref| 0| 0
> (1 row)
>
> -- ******** Ooops - where are they gone?
>
> doc=> explain select distinct refpage from doc_wordref
> dos-> where refword ~ '^a';
> NOTICE: QUERY PLAN:

I have seen the optimizer stop using indexes, but could never reproduce
it, and hoped my mega-patch would have fix it.

My only guess is that vacuum has changed the buffer cache copy of the
pg_class tuple, but did not mark it as dirty, so it was not written back
out when removed from the buffer cache. When reloaded after the query,
the buffer cache is loaded from the disk copy, and the disk copy has
zeros, because the vacuum copy was not written to disk.

The active code is in vacuum.c::vc_updstats:

/* XXX -- after write, should invalidate relcache in other backends */
WriteNoReleaseBuffer(ItemPointerGetBlockNumber(&rtup->t_ctid));

RelationInvalidateHeapTuple(rd, rtup);

This should be marking the buffer as dirty and written out the buffer to
disk, so when it gets reloaded, it has the new vacuum statatistics. It
is also invalidating the catalog cache, so that doesn't get used for
stats.

The code looks fine to me. I can't figure out why that would happen.
Can you try replacing WriteNoReleaseBuffer() with WriteBuffer() and see
if that fixes it.

--
Bruce Momjian | http://www.op.net/~candle
maillist(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026