From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: Opteron scaling with PostgreSQL |
Date: | 2004-06-12 23:54:05 |
Message-ID: | 873c50s57m.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Greg Stark <gsstark(at)mit(dot)edu> writes:
> > Steve Wolfe <nw(at)codon(dot)com> writes:
> >> I've run with fsync off on my production servers for years.
>
> > All it will take will be a Linux crash for the database files on disk to
> > become corrupted. No amount of UPS or RAID protection will protect from that.
>
> And neither will fsync'ing, so I'm not sure what your point is.
Uhm, well a typical panic causes the machine to halt. It's possible that
causes the OS to scribble all over disk if that's what you mean, but it's
pretty rare. Usually I just get random reboots or halts when things are going
wrong. In that case you have a consistent database if you use fsync but not if
you don't.
> Steve clearly understands the need for backups, so I think he's prepared as
> well as he can for worst-case scenarios. He's determined that the particular
> scenarios fsync can protect him against are not big enough risks *in his
> environment* to justify the cost. I can't say that I see any flaws in his
> reasoning.
I wasn't disagreeing with that. Just trying to ensure that it was clear what
the risk was. Without fsync anything that causes the OS to stop flushing
blocks without syncing including power loss but also including a panic of any
kind could (and probably would I would think) corrupt the DB.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2004-06-13 00:26:31 | Re: Trying to minimize the impact of checkpoints |
Previous Message | Tom Lane | 2004-06-12 20:53:38 | Re: [HACKERS] Release 7.4.3 branded |