Re: Can we trust fsync?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Craig Ringer <craig(at)2ndquadrant(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Can we trust fsync?
Date: 2013-11-22 16:16:06
Message-ID: 28042.1385136966@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, it's not that hard to do plug-pull testing to verify that your
>> system is telling the truth about fsync. This really ought to be part
>> of acceptance testing for any new DB server.

> I've never tried it but I always wondered how easy it was to do. How would
> you ever know you had tested it enough?

I used the program Greg Smith recommends on our wiki (can't remember the
name offhand) when I got a new house server this spring. With the RAID
card configured for writethrough and no battery, it failed all over the
place. Fixed those configuration bugs, it was okay three or four times
in a row, which was good enough for me.

> The original mail was referencing a problem with syncing *meta* data
> though. The semantics around meta data syncs are much less clearly
> specified, in part because file systems traditionally made nearly all meta
> data operations synchronous. Doing plug-pull testing on Postgres would not
> test meta data syncing very well since Postgres specifically avoids doing
> much meta data operations by overwriting existing files and blocks as much
> as possible.

True. You're better off with a specialized testing program. (Though
now you mention it, I wonder whether that program was stressing metadata
or not.)

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-22 16:27:45 Re: Building on S390
Previous Message Greg Stark 2013-11-22 16:04:16 Re: Can we trust fsync?