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

From: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM>, "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?)
Date: 2000-05-26 03:17:18
Message-ID: 000601bfc6c0$e5d00920$2801007e@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> -----Original Message-----
> From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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(at)tpf(dot)co(dot)jp

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2000-05-26 03:31:24 Re: vacuum analyze feedback
Previous Message Hiroshi Inoue 2000-05-26 03:16:06 RE: Orphaned locks in 7.0?