> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> > 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.)
>
Agreed.
However,BM_DIRTY+BM_IO_ERROR buffers seems to have to be
excluded from freelist of buffers. Then IO errors would be limited
to backends which really need to update the buffers.
> 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
You are right.
> 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.
>
Sounds reasonbale.
Regards.
Hiroshi Inoue