Re: Can we trust fsync? - Mailing list pgsql-hackers

From Greg Stark
Subject Re: Can we trust fsync?
Date
Msg-id CAM-w4HODzQ_DKUtGGCfjoh=WnrNLXj=iJpQV4rE78pcRpA5c5w@mail.gmail.com
Whole thread Raw
In response to Re: Can we trust fsync?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Can we trust fsync?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
<div dir="ltr"><div class="gmail_extra"><br /><div class="gmail_quote">On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane <span
dir="ltr"><<ahref="mailto:tgl@sss.pgh.pa.us" target="_blank">tgl@sss.pgh.pa.us</a>></span> wrote:<br
/><blockquoteclass="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3r8"
style="overflow:hidden">Also, it's not that hard to do plug-pull testing to verify that your<br /> system is telling
thetruth about fsync.  This really ought to be part<br /> of acceptance testing for any new DB
server.</div></blockquote></div><br/></div><div class="gmail_extra">I've never tried it but I always wondered how easy
itwas to do. How would you ever know you had tested it enough?<br /><br /><br /></div><div class="gmail_extra">The
originalmail was referencing a problem with syncing *meta* data though. The semantics around meta data syncs are much
lessclearly specified, in part because file systems traditionally made nearly all meta data operations synchronous.
Doingplug-pull testing on Postgres would not test meta data syncing very well since Postgres specifically avoids doing
muchmeta data operations by overwriting existing files and blocks as much as possible. You would have to test doing
tableextensions or pulling the plug immediately after switching xlog files repeatedly to have any coverage at all
there.<br/></div><div class="gmail_extra"><br clear="all" /><br />-- <br />greg<br /></div></div> 

pgsql-hackers by date:

Previous
From: Michael Meskes
Date:
Subject: Building on S390
Next
From: Tom Lane
Date:
Subject: Re: Can we trust fsync?