RE: Fwd: Postgres update

> -----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