Re: test_fsync label adjustments

A.M. wrote:
> 
> On Jan 18, 2011, at 5:41 PM, Bruce Momjian wrote:
> 
> > A.M. wrote:
> >>>> Because the fastest option may not be syncing to disk. For example,
> >>>> the only option that makes sense on OS X is fsync_writethrough- it
> >>>> would be helpful if the tool pointed that out (on OS X only, obviously).
> >>> 
> >>> Yes, that would be a serious problem.  :-(
> >>> 
> >>> I am not sure how we would address this --- your point is a good one.
> >> 
> >> One general idea I had would be to offer some heuristics such as "this
> >> sync rate is comparable to that of one SATA drive" or "comparable to
> >> RAID 10 with X drives" or "this rate is likely too fast to be actually
> >> be syncing". But then you are stuck with making sure that the heuristics
> >> are kept up-to-date, which would be annoying.
> > 
> > That fails for RAID BBUs.
> 
> Well, it's nothing more than a heuristic- it is still nice to know whether or not the fancy hardware RAID I just
setupis similar to Josh Berkus' RAID setup or a single SATA drive (which would hint at a misconfiguration). As you
said,perhaps a wiki is better for this. But a wiki won't integrate with this tool, which I why I would hesitate to
pointnovices to this tool... should the tool point to the wiki?
 
> 
> > 
> >> Otherwise, the only option I see is to detect the kernel and compare
> >> against a list of known problematic methods. Perhaps it would be easier
> >> to compare against a whitelist. Also, the tool would likely need to
> >> parse "mount" output to account for problems with specific filesystems.
> >> 
> >> I am just throwing around some ideas...
> > 
> > That sounds pretty complicated.  One idea would be the creation of a
> > wiki where people could post their results, or ideally a tool that could
> > read the output and load it into a database for analysis with other
> > results.
> 
> The OS X example is pretty cut-and-dry- it would be nice if there were
> some kind of hints in the tool pointing in the right direction, or at
> least a few words of warning: "the fastest option may not be the safest-
> read the docs".

We have a wal reliability section in the docs that attempts to address
this:
http://developer.postgresql.org/pgdocs/postgres/wal-reliability.html

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +