Re: PG 7.0 vacuum problem - Mailing list pgsql-general

From Tom Lane
Subject Re: PG 7.0 vacuum problem
Date
Msg-id 803.959298540@sss.pgh.pa.us
Whole thread Raw
In response to PG 7.0 vacuum problem  (Marcin Inkielman <marn@wsisiz.edu.pl>)
Responses Re: PG 7.0 vacuum problem  (Marcin Inkielman <marn@wsisiz.edu.pl>)
List pgsql-general
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...

            regards, tom lane

pgsql-general by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: initdb and "exit_nicely"...
Next
From: Tom Lane
Date:
Subject: Re: initdb and "exit_nicely"...