Re: PG 7.0 vacuum problem
От | Marcin Inkielman |
---|---|
Тема | Re: PG 7.0 vacuum problem |
Дата | |
Msg-id | Pine.LNX.4.21.0005260202120.458-100000@mi.marnnet обсуждение исходный текст |
Ответ на | Re: PG 7.0 vacuum problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-general |
On Thu, 25 May 2000, Tom Lane wrote: > Date: Thu, 25 May 2000 19:49:00 -0400 > From: Tom Lane <tgl@sss.pgh.pa.us> > To: Marcin Inkielman <marn@wsisiz.edu.pl> > Cc: pgsql-general@postgresql.org > Subject: Re: [GENERAL] PG 7.0 vacuum problem > > Marcin Inkielman <marn@wsisiz.edu.pl> 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 <tmp > > 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 по дате отправления: