Re: pgsql-server: Add: > > * Allow buffered WAL writes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server: Add: > > * Allow buffered WAL writes
Date: 2004-08-14 22:05:10
Message-ID: 7633.1092521110@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> One question, more directed to Tom here ... since they are seperate right
> now, if WAL is fsync, and "regular writing" is no-fsync, doesn't that
> potentially open us up to some *serious* problems? WAL sees the
> transaction as complete, but the write for the rest of the system hasn't
> happened yet?

No, that's pretty much the whole point of WAL: once you've fsynced the
transaction's log entries to WAL, it's committed. You don't have to
fsync the data-file writes, or even write the changes out at all.
(In most cases the pages stay in shared buffer cache, dirty, until the
background writer gets to them.) If you crash then the data-file
changes will get redone by replaying the WAL entries.

You do have to fsync data-file writes when trying to complete a
checkpoint, but that's outside the critical path for normal
transactions.

One of the reasons I dislike Bruce's proposal is that I don't think it
pays any attention to this basic duality between normal operations
(fsync WAL) and checkpoints (fsync data). We just finished finding a
long-standing bug in this area, so I'm pretty hesitant to whack it
around on the basis of unproven ideas about performance improvements.

regards, tom lane

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2004-08-14 22:17:08 pgsql-server: Minor editorializing.
Previous Message Bruce Momjian 2004-08-14 20:15:56 Re: pgsql-server: Add: > > * Allow buffered WAL writes