> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > As far as I see,PostgreSQL doesn't call LockBuffer() before
> > calling smgrwrite(). This seems to mean that smgrwrite()
> > could write buffers to disk which are being changed by
> > another backend. If the(another) backend was aborted by
> > some reason the buffer page would remain half-changed.
>
> Hmm ... looks fishy to me too. Seems like we ought to hold
> BUFFER_LOCK_SHARE on the buffer while dumping it out. It
> wouldn't matter under normal circumstances, but as you say
> there could be trouble if the other backend crashed before
> it could mark the buffer dirty again, or if we had a system
> crash before the dirtied page got written again.
Well, known issue. Buffer latches were implemented in 6.5 only
and there was no time to think about subj hard -:)
Yes, we have to shlock buffer before writing and this is what
bufmgr will must do for WAL anyway (to ensure that last buffer
changes already logged)... but please check that buffer is not
exc-locked by backend itself somewhere before smgrwrite()...
Vadim