Thread: what is flushed?

I was reading "Don't be lazy, be consistent: Postgres-R,
a new way to implement Database Replication"
and I found this:

"5.1 General configuration
PostgreSQL uses a force strategy to avoid redo recov­ery,
flushing all dirty buffer pages at the end of each
transaction. With this strategy, response times are
very poor. This makes it difficult to compare with
commercial systems which only flush redo logs to disk.
To allow us to use a more ``realistic'' setting we used
the no­flush option offered by PostgreSQL. With this
option nothing is forced to disk, not even a log record.
This, of course, violates the ACID properties, how­
ever the measured response time was better compara­ble
to standard database systems."

The doc uses Postgresql version 6.4.2.
Has this behaviour been changed?
From the docs of the 7.4 I got that only the redo logs are flushed...

Or am I wrong?

On Wed, Sep 15, 2004 at 04:10:29PM +0200, Leonardo Francalanci wrote:
> I was reading "Don't be lazy, be consistent: Postgres-R,
> a new way to implement Database Replication"
> and I found this:
>
> "5.1 General configuration
<snip>

> The doc uses Postgresql version 6.4.2.
> Has this behaviour been changed?
> >From the docs of the 7.4 I got that only the redo logs are flushed...

WAL has been a feature of Postgresql for years now... So yes, it's
somewhat out of date...
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

Martijn van Oosterhout <kleptog@svana.org> writes:

> WAL has been a feature of Postgresql for years now... So yes, it's
> somewhat out of date...

Actually it kind of depends what it means. I think WAL records were always
written with fsync (or fdatasync/O_SYNC/O_DSYNC).

However right up until 7.4 checkpointing was done with sync(2). This means
that other unrelated i/o could cause unneeded delay at checkpoint time. This
would have been an especially big hit for shared servers running other
write-intensive services such as, say, mail.

The impetus to finally fix this came from the Windows port since Windows
simply didn't have sync(2). Afaik 8.0 won't have to issue a sync(2) call ever.

--
greg