smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?) - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?)
Date
Msg-id 000601bfc6c0$e5d00920$2801007e@tpf.co.jp
Whole thread Raw
In response to Re: Shouldn't flush dirty buffers at shutdown ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?)
List pgsql-hackers
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
>
> "Hiroshi Inoue" <Inoue@tpf.co.jp> writes:
> > What I've never understood until recently is that even normal aborts(not
> > in the middle of b-tree splitting) and normal shutdown could cause an
> > inconsistency between heap and indices.
>
> Yes.  Since WAL will provide the real solution in 7.1, I think we need
> only look for a simple stopgap answer for 7.0.x.  Perhaps we could just
> tweak bufmgr.c so that dirty buffers are flushed out on both transaction
> commit and abort.  That doesn't solve the consistency-after-crash issue,
> but at least you can do an orderly shutdown of a postmaster without
> fear.  Is it worth trying to do more now, rather than working on WAL?
>

I have another anxiety now.
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.

Is it well known ?  Please correct me if I'm wrong.

Regards.

Hiroshi Inoue
Inoue@tpf.co.jp



pgsql-hackers by date:

Previous
From: "Hiroshi Inoue"
Date:
Subject: RE: Orphaned locks in 7.0?
Next
From: Philip Warner
Date:
Subject: Re: vacuum analyze feedback