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