"Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> 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.
Right, that's why we can't just mark the buffer broken and recycle it.
If there is another transaction in progress that's dirtied that same
buffer, it would come back, find the disk page no longer present in that
buffer, conclude that its changes were successfully written, and go
ahead and commit. No good, it has to fail. So, leave the buffer
sitting there marked BM_DIRTY + BM_IO_ERROR. When the other xact wants
to commit, it will try to write the buffer, fail, and abort. (Or,
if perchance it doesn't fail, that's OK too.)
The only way to discard the buffer short of a postmaster reset would be
if we knew no current transaction could have dirtied the buffer. Hmm,
I wonder if we could have VACUUM do that before it starts the main
vacuuming process? If we have exclusive lock on the table, then
presumably there can be no other xacts with pending changes. So maybe
the first step of VACUUM could be to sweep the buffer table for buffers
of that relation that are marked BM_DIRTY + BM_IO_ERROR, and discard
them? Not sure about this.
Also, I think deleting the relation that owns the broken buffer will
clean it up correctly in current sources --- ReleaseRelationBuffers
doesn't care if the buffer is dirty or not.
regards, tom lane
