RE: FlushRelationBuffers returned -2

> Magnus Hagander <mha@sollentuna.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.
I don't *think* there should be anything like that. Looking at my log, there
are the following entries (other than the usual "unexpected EOF on client
connection" from scripts that are aborted...

ERROR:  regcomp failed with error empty (sub)expression
pq_flush: send() failed: Broken pipe
ERROR:  Named portals may only be used in begin/end transaction blocks

Apart from that, it's just the usual EXPLAIN output and misspelled queries
(complaning about tables taht don't exist, etc, when somebody misspelled
them). All these queries worked with other tables, but in the same database
(a partially different project).

There is no "core" file anywhere in the pgsql directory structure, and
nothing in the log about any backend crash.

I'll keep my eyes open if it happens again, and try to find a pattern.


> 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.
Ok. Better safe than sorry :-) Good to know.

//Magnus