RE: smgrwrite() without LockBuffer(was RE: Shouldn't fl ush dirty buffers at shutdown ?)

From: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>
To: "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: smgrwrite() without LockBuffer(was RE: Shouldn't fl ush dirty buffers at shutdown ?)
Date: 2000-05-26 07:00:26
Message-ID: 8F4C99C66D04D4118F580090272A7A23018C07@SECTORBASE1
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Mount 2000-05-26 08:08:28 RE: Postgresql 7.0 JDBC exceptions - broken connecti ons ?
Previous Message Peter Mount 2000-05-26 06:43:08 RE: Create user/create database outside template1