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@candle.pha.pa.us            |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026