Re: fsync = true beneficial on ext3?
От | scott.marlowe |
---|---|
Тема | Re: fsync = true beneficial on ext3? |
Дата | |
Msg-id | Pine.LNX.4.33.0402100909260.28531-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: fsync = true beneficial on ext3? ("Jim C. Nasby" <jim@nasby.net>) |
Список | pgsql-general |
I can see you never took statistics... On Mon, 9 Feb 2004, Jim C. Nasby wrote: > Actually, I don't think even that is a valid test. The absence of a > failure doesn't mean one can't occur in this case. Doesn't matter if you > try the test 1 or 10,000 times; the test will only be conclusive if you > actually see a failure. > > On Mon, Feb 09, 2004 at 10:19:15AM -0700, scott.marlowe wrote: > > On Sun, 8 Feb 2004, Ed L. wrote: > > > > > > > > I'm curious what the consensus is, if any, on use of fsync on ext3 > > > filesystems with postgresql 7.3.4 or later. I did some recent performance > > > tests demonstrating a 45%-70% performance improvement for simple inserts > > > with fsync off on one particular system. Does fsync = true buy me any > > > additional recoverability beyond ext3's journal recovery? > > > > > > If we write something without sync'ing, presumably it's immediately > > > journaled? So even if the DB crashes prior to fsync'ing, are we fully > > > recoverable? I've been running a few pgsql clusters on ext3 with fsync = > > > false, suffered numerous OS crashes, and have yet to lose any data or see > > > any corruption from any of those crashes. Have I just been lucky? > > > > With all the other posts on this topic, I just want to point out that it's > > all theory until you build your machine, set it up, initiate a hundred or > > so parallel transactions, and pull the plug in the middle. > > > > Without pulling the plug, you just don't know for sure. And you need to > > do it a few times, in case your machine "got lucky" once and might fail on > > subsequent power fails. > > > > > > ---------------------------(end of broadcast)--------------------------- > > TIP 4: Don't 'kill -9' the postmaster > > > >
В списке pgsql-general по дате отправления: