Re: [HACKERS] The dangers of "-F"
От | Don Baccus |
---|---|
Тема | Re: [HACKERS] The dangers of "-F" |
Дата | |
Msg-id | 3.0.1.32.19990622163855.00d030e4@mail.pacifier.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] The dangers of "-F" (Bruce Momjian <maillist@candle.pha.pa.us>) |
Ответы |
Re: [HACKERS] The dangers of "-F"
|
Список | pgsql-hackers |
At 06:38 PM 6/22/99 -0400, Bruce Momjian wrote: >No Fsync is only dangerous if your OS or hardware crashes without >flushing the disk. Anything else is unaffected, and is just as reliable. Yes, this much I realize... >The database could be inconsistent, in the sense that partial >transactions are recorded as completed. With recovery possible without a rebuild? Or is rebuilding from dumps required? (I dump nightly and copy the results to a second machine for additional safety, and soon will be ftp'ing dump files to the east coast for even more safety). Perhaps fsync'ing then is only LESS dangerous, since a system can crash while blocks are being written even when fsync is enabled. The window of evil opportunity for a system crash is much smaller than if the data's sitting around for a lengthy time in the Linux FS cache, of course, but not absent. Or does the fact that the backend loses control over the order in which stuff is written (in other words, blocks are written whenever and in what order Linux choses rather than fsync'd a file at a time) mean that the kind of inconsistency that might result is different? I.E. log file written before datablocks are, that kind of thing. >I think it is a major issue too. Is there any estimate of the difficulty of fixing it? >From previous discussions, it sounded as though new bookkeeping would be needed to determine which queries actually result in a change in data. - Don Baccus, Portland OR <dhogaza@pacifier.com> Nature photos, on-line guides, and other goodies at http://donb.photo.net
В списке pgsql-hackers по дате отправления: