| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Joseph Shraibman <jks(at)selectacast(dot)net> |
| Cc: | "pgsql-general(at)hub(dot)org" <pgsql-general(at)hub(dot)org> |
| Subject: | Re: vacuum messges |
| Date: | 2000-07-31 19:15:42 |
| Message-ID: | 10242.965070942@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Joseph Shraibman <jks(at)selectacast(dot)net> writes:
> What do these mean?
> NOTICE: FlushRelationBuffers(message, 2): block 2 is referenced
> (private 0,
> global 1)
> FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
We've seen a couple reports of this happening with 7.0. Apparently
there is a buffer-reference-count leak happening somewhere, such that
a disk buffer is still marked as busy even though (presumably) nothing
but VACUUM is actually touching the table. When VACUUM sees this, it
punts for fear of creating problems.
You can recover by restarting the postmaster, but the really interesting
question is how the system gets into this state in the first place.
If you can work out a reproducible or semi-reproducible sequence for
causing the problem to occur, please tell us!
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2000-07-31 19:17:58 | Re: Corrupted Table |
| Previous Message | database | 2000-07-31 19:15:40 | hierarchy select question? |