Re: performance of insert/delete/update
От | Josh Berkus |
---|---|
Тема | Re: performance of insert/delete/update |
Дата | |
Msg-id | 200211231329.20384.josh@agliodbs.com обсуждение исходный текст |
Ответ на | Re: performance of insert/delete/update (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: performance of insert/delete/update
|
Список | 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
В списке pgsql-performance по дате отправления: