| 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 |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-11-23 21:41:37 | Re: performance of insert/delete/update |
| Previous Message | Tom Lane | 2002-11-23 21:20:39 | Re: performance of insert/delete/update |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-11-23 21:41:37 | Re: performance of insert/delete/update |
| Previous Message | Tom Lane | 2002-11-23 21:20:39 | Re: performance of insert/delete/update |