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

Поиск
Список
Период
Сортировка
От Hiroshi Inoue
Тема smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?)
Дата
Msg-id 000601bfc6c0$e5d00920$2801007e@tpf.co.jp
обсуждение исходный текст
Ответ на Re: Shouldn't flush dirty buffers at shutdown ?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: smgrwrite() without LockBuffer(was RE: Shouldn't flush dirty buffers at shutdown ?)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Hiroshi Inoue"
Дата:
Сообщение: RE: Orphaned locks in 7.0?
Следующее
От: Philip Warner
Дата:
Сообщение: Re: vacuum analyze feedback