From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Marcin Inkielman <marn(at)wsisiz(dot)edu(dot)pl> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: PG 7.0 vacuum problem |
Date: | 2000-05-25 23:49:00 |
Message-ID: | 803.959298540@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Marcin Inkielman <marn(at)wsisiz(dot)edu(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2000-05-25 23:53:14 | Re: initdb and "exit_nicely"... |
Previous Message | Marcin Inkielman | 2000-05-25 23:11:03 | PG 7.0 vacuum problem |