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 setup is 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 point novices 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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers