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

> > I think the simple way of modifying the tuple in the page
> > does not work. I found that catalog/index.c does the same for
> > relpages and reltuples in UpdateStats(). Calling
> > UpdateStats() after vc_updstats() as a quick hack solved the
> > problem.
>
> And now I know the way of modifying them in the buffer is the
> only one to succeed. Doing it like index.c with
> heap_replace() irritates vacuum itself.
>
> Sometimes it's good to check returncodes :-).
> WriteNoReleaseBuffer() (as it's name says) takes a buffer
> number as argument, not a disk block number. Thus, it
> returned FALSE sometimes when called to write buffer # 0.
>
> The attdisbursion is also permanently saved on disk now. It
> had the same problem.
>
> Anyway, the fix is below.
>
> Patch is regression tested.

Applied. Thanks.

I am glad you were able to find the actual cause, rather than calling
that UpdateStats function. Vacuum is too strange in the way it modifies
things, and calling a general-purpose function that calls all sorts of
other functions could be a problem.

Of course, you are right. I was passing in a block number, rather than
a buffer number. I checked 6.3.2, and I had it right there, so somehow
I got confused in the megapatch on that item. I just checked the
mega-patch, and that is the only place I used ItemPointerGetBlockNumber
as a replacement for Buffer.

Glad to see you were able to make sense of the new heap_fetch() syntax
to get the buffer. The old code was very unclear in these areas. Now
that it is in the developers FAQ, it should be better.

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