> > 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?
I get this after the following:
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: NOTICE: !!! write error seems permanent
!!!psql:/home/www/www.webmailstation.com/sql/reindex.sql:75:NOTICE: !!! now kill all backends and reset postmaster
!!!
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: ERROR: cannot write block 175 of ix_q_b_1 [webmailstation]
blind
pqReadData() -- backend closed the channel unexpectedly.This probably means the backend terminated abnormallybefore or
whileprocessing the request.
psql:/home/www/www.webmailstation.com/sql/reindex.sql:75: connection to server was lost
This was the command which should create unique index. Something happend and
index became corrupted. After that postgres starts to eat up memory and I killed him.
I recognized that this happend on update of the table on which the index was build and
that update uses the index.
It is hard to reproduce this...
I would like to give you binary data, but unfortunatly I was forced
to rebuild index ASAP and has finished investigation later...
--
Sincerely Yours,
Denis Perchine
----------------------------------
E-Mail: dyp@perchine.com
HomePage: http://www.perchine.com/dyp/
FidoNet: 2:5000/120.5
----------------------------------
