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
> I get this after the following:
> NOTICE: !!! write error seems permanent !!!
> NOTICE: !!! now kill all backends and reset postmaster !!!
> ERROR: cannot write block 175 of ix_q_b_1 [webmailstation] blind
> pqReadData() -- backend closed the channel unexpectedly.
Oh, that's interesting. The NOTICEs are coming out of AbortBufferIO()
which is invoked during error processing (in other words, I bet the
ERROR actually happened first. It's a libpq artifact that the NOTICEs
are presented first on the client side. If you are keeping the
postmaster log output you could confirm the sequence of events by
looking in the log). The backend shutdown is then forced by
AbortBufferIO().
AbortBufferIO() seems rather badly designed, but given that it forces
a database-wide restart, I'm not sure how this could relate to the
later FlushRelationBuffers problem. The restart should get rid of the
old buffers anyway.
> This was the command which should create unique index.
Was the index on the same table that FlushRelationBuffers later had
trouble with (ie, "pg_largeobject")?
What version are you running, anyway? There is no "pg_largeobject"
in either 6.5 or current AFAIK.
regards, tom lane
