On Fri, Nov 22, 2013 at 11:16:06AM -0500, Tom Lane wrote:
> Greg Stark <st...@mit.edu> writes:
> > On Thu, Nov 21, 2013 at 1:43 AM, Tom Lane <t...@sss.pgh.pa.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.)
The program is diskchecker:
http://brad.livejournal.com/2116715.html
I got the author to re-host the source code on github a few years ago.
--
Bruce Momjian <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
