Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

shells and bells



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).




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org