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

Поиск
Список
Период
Сортировка
От jwieck@debis.com (Jan Wieck)
Тема Re: [HACKERS] Bug? relpages, reltuples resets to zero
Дата
Msg-id m0zWejK-000EBPC@orion.SAPserv.Hamburg.dsh.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Bug? relpages, reltuples resets to zero  (Bruce Momjian <maillist@candle.pha.pa.us>)
Ответы Re: [HACKERS] Bug? relpages, reltuples resets to zero
Список pgsql-hackers
Bruce Momjian wrote:

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

    Your guess was right, thanks. But your solution does not work
    :-(

    I found a way to easily reproduce the error.

         Run VACUUM
         Restart postmaster
         -> relpages and reltuples gone

    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.

    I'm now cvsup'ing, then I'll modify vacuum.c  to  do  it  the
    same  way  as  index.c  does  it.  I  don't  know  if calling
    UpdateStats() instead is really a good idea,  because  vacuum
    potentially    truncates   files   and   UpdateStats()   does
    RelationGetNumberOfBlocks()  instead   of   getting   it   by
    argument. This might be wrong at that time.

    Let's see what happens when vacuum does it harder.


Later, Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me.                                  #
#======================================== jwieck@debis.com (Jan Wieck) #

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

Предыдущее
От: The Hermit Hacker
Дата:
Сообщение: Re: [HACKERS] Re: y2k
Следующее
От: darcy@druid.net (D'Arcy J.M. Cain)
Дата:
Сообщение: Re: [HACKERS] 6.4 interfaces deadline