Re: PG 7.0 vacuum problem

Поиск
Список
Период
Сортировка
Искать
От
Marcin Inkielman
Тема
Re: PG 7.0 vacuum problem
Дата
в 20:19:30
Msg-id
Pine.LNX.4.21.0005260202120.458-100000@mi.marnnet
Ответ на
Список
Дерево обсуждения
Re: problem with NOTICE: _outNode: don't know how to print type Martijn van Oosterhout <kleptog@cupid.suninternet.com>
On Thu, 25 May 2000, Tom Lane wrote:

> Date: Thu, 25 May 2000 19:49:00 -0400
> From: Tom Lane 
> To: Marcin Inkielman 
> Cc: pgsql-general@postgresql.org
> Subject: Re: [GENERAL] PG 7.0 vacuum problem 
> 
> Marcin Inkielman  writes:
> > i rescently upgraded my system from PG6.53 to PG7.0. after a few days of
> > work i am unable to do a vacuum on one of tables:
> 
> > nat=# VACUUM verbose analyze osoby;
> > NOTICE:  FlushRelationBuffers(osoby, 182): block 186 is referenced
> > (private 0, global 3)
> > FATAL 1:  VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
> 
> Hmm.  Have you had any backend crashes?  What seems to be happening here
> is that there are some leftover reference counts on one of the shared
> disk buffers for that relation.  That should never be true while VACUUM
> is running, because no other backend is supposed to be referencing that
> table.
> 
> > do i risk anything if i do:
> 
> > pg_dump nat> tmp
> > dropdb nat
> > createdb nat
> > psql nat  
> Probably won't work either.  Instead, try stopping and restarting the
> postmaster --- if my theory is right, that should get rid of the
> leftover reference counts.  But the real question is how did it get
> into this state in the first place...

thanks, it worked! before this, i tried to recreate my database using
another name (and without destroying the old one) - it worked too!

-- 
mi

В списке pgsql-general по дате отправления
От: Tom Lane
Дата:
От: J.R.
Дата:
FAQ