Skip site navigation (1) Skip section navigation (2)

Re: performance of insert/delete/update

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net>,PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: performance of insert/delete/update
Date: 2002-11-23 21:29:20
Message-ID: 200211231329.20384.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Tom,

> When you get right down to it, what we use fsync for is to force write
> ordering --- Unix kernels do not guarantee write ordering any other way.
> We use it to ensure WAL records hit disk before data file changes do.
> 
> Bottom line: I wouldn't run with fsync off in a mission-critical
> database.  If you're prepared to accept a risk of having to restore from
> your last backup after a system crash, maybe it's okay.

Thanks for that overview.  Sadly, even with fsynch on, I was forced to restore 
from backup because the data needs to be 100% reliable and the crash was due 
to a disk lockup on a checkpoint ... beyond the ability of WAL to deal with, 
I think.

One last, last question:  I was just asked a question on IRC, and I can't find 
docs defining fsynch, fdatasynch, opensynch, and opendatasynch beyond section 
11.3 which just says that they are all synch methods.   Are there docs?


-- 
-Josh Berkus
 Aglio Database Solutions
 San Francisco


In response to

Responses

pgsql-performance by date

Next:From: Tom LaneDate: 2002-11-23 21:41:37
Subject: Re: performance of insert/delete/update
Previous:From: Tom LaneDate: 2002-11-23 21:20:39
Subject: Re: performance of insert/delete/update

pgsql-hackers by date

Next:From: Tom LaneDate: 2002-11-23 21:41:37
Subject: Re: performance of insert/delete/update
Previous:From: Tom LaneDate: 2002-11-23 21:20:39
Subject: Re: performance of insert/delete/update

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group