Re: Fwd: Postgres update - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fwd: Postgres update
Date
Msg-id 29641.964796761@sss.pgh.pa.us
Whole thread Raw
In response to Fwd: Postgres update  (Denis Perchine <dyp@perchine.com>)
Responses Re: Fwd: Postgres update  (Denis Perchine <dyp@perchine.com>)
List pgsql-hackers
Denis Perchine <dyp@perchine.com> writes:
> NOTICE:  FlushRelationBuffers(pg_largeobject, 515): block 504 is referenced (private 0, global 1)
> FATAL 1:  VACUUM (repair_frag): FlushRelationBuffers returned -2

Hmm, there's another report of that in the archives.  You've got a
buffer that has a positive reference count even though (presumably)
no one is using it.  VACUUM is quitting out of paranoia that maybe
some other backend is accessing the table --- there's unlikely to be
any actual data corruption here, just (over?) caution.

You can get back to a state where VACUUM will work on the table by
restarting the postmaster, but to fix the real problem we need to figure
out how the system got into this state in the first place.  Can you
produce a repeatable example of a series of queries that gets you into
this state?
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Questionable coding in proc.c & lock.c
Next
From: Tom Lane
Date:
Subject: Re: toasting for other varlena types