> -----Original Message-----
> From: pgsql-hackers-owner@hub.org [mailto:pgsql-hackers-owner@hub.org]On
> Behalf Of Tom Lane
>
> 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
It was me who introduced xxxxBufferIO routines to avoid io_in_progress
spinlock freezing. Unfortunately I didn't think of any elegant way to
recover parmanent write error then. I'm judging the error is parmanent
when write error for the buffer occurs twice.
Because you changed bufmgr before 7.0,we may be able to avoid a
database-wide restart. However don't we have to leave the buffer
still dirty even after your change ? If I recognize correctly,we couldn't
know which backends dirtied the buffer. Even though we could know
it,we couldn't know if the transactions which dirtied the buffer are still
running.
Regards.
Hiroshi Inoue
