From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <mha(at)sollentuna(dot)net> |
Cc: | "'pgsql-hackers(at)postgresql(dot)org'" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: FlushRelationBuffers returned -2 |
Date: | 2000-07-18 15:08:54 |
Message-ID: | 18002.963932934@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <mha(at)sollentuna(dot)net> writes:
> I noticed my nightly vacuum process has started dying on a certain relation
> last night. When I try to vaccum verbose it, I get the following output.
> NOTICE: FlushRelationBuffers(filelist, 310): block 0 is referenced (private
> 0, global 5)
> FATAL 1: VACUUM (vc_repair_frag): FlushRelationBuffers returned -2
> Restarting the postmaster corrected the problem.
That's what I was about to suggest trying. It sounds like something
crashed and left the buffer reference count incremented above zero for
one of the pages of the relation. In fact, several somethings, five of
them to be exact.
Have you had any interesting backend crashes lately? Are you doing
anything unusual with that table? It would seem that whatever is causing
this is at least moderately reproducible in your environment, since it's
happened more than once. It'd be easier to track down if you could
identify what sequence of operations causes the buffer refcount to be
left incremented.
BTW, don't be afraid of the fact VACUUM aborts --- it's just being
paranoid about the possibility that someone else is using this table
that it's supposed to have an exclusive lock on.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2000-07-18 16:21:23 | RE: FlushRelationBuffers returned -2 |
Previous Message | Tom Lane | 2000-07-18 14:52:20 | Re: Untrusted PL/Tcl? |