shells and bells

[Mike Bilow]

This is actually controllable in PostgreSQL in the "postmaster.init" file:

# Whether to disable the fsync() call after each transaction. (If fsync() is
# disabled, performance will improve at the cost of an increased risk of data
# corruption in the event of power or other hardware failure.): yes/no
# PGFSYNC=yes (i.e. the fsync() call does not happen)

Obviously, this would be ignored on an operating system which does not
allow support for fsync() calls.  Note that fsync() is POSIX-standard.

The compile-time default of PostgreSQL is not to use fsync().

-- Mike


On 2000-05-03 at 22:26 -0400, Derek Martin wrote:

> As I understand the problem (and I'll admit up front that my understanding
> may be flawed), this is due to the fact that a database write, while
> "atomic" from the database's perspective, is not an atomic operation from
> the kernel's perspective, unless the whole operation can be done with
> exactly one system call (system calls are guaranteed to be atomic, IIRC).
> Otherwise, the dbms may finish its time slice while a record update is in
> progress, at which time the back-up program may read the database's files,
> yeilding spaghetti data on your backup tape.


-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).