Greg Smith wrote: > Bruce Momjian wrote: > > I thought our only problem was testing the I/O subsystem --- I never > > suspected the file system might lie too. That email indicates that a > > large percentage of our install base is running on unreliable file > > systems --- why have I not heard about this before? Do the write > > barriers allow data loss but prevent data inconsistency? It sound like > > they are effectively running with synchronous_commit = off. > > > You might occasionally catch me ranting here that Linux write barriers > are not a useful solution at all for PostgreSQL, and that you must turn > the disk write cache off rather than expect the barrier implementation > to do the right thing. This sort of buginess is why. The reason why it > doesn't bite more people is that most Linux systems don't turn on write > barrier support by default, and there's a number of situations that can > disable barriers even if you did try to enable them. It's still pretty > unusual to have a working system with barriers turned on nowadays; I > really doubt it's "a large percentage of our install base".
Ah, so it is only when write barriers are enabled, and they are not enabled by default --- OK, that makes sense. > I've started keeping most of my notes about where ext3 is vulnerable to > issues in Wikipedia, specifically > http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journal ; I just > updated that section to point out the specific issue Ron pointed out. > Maybe we should point people toward that in the docs, I try to keep that > article correct. Yes, good idea. -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
