Received: from maia.hub.org (maia-4.hub.org [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id 8051C632509 for ; Mon, 10 May 2010 14:47:26 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 98363-03 for ; Mon, 10 May 2010 17:47:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by mail.postgresql.org (Postfix) with ESMTP id B3278632832 for ; Mon, 10 May 2010 14:47:14 -0300 (ADT) Received: by pzk11 with SMTP id 11so1850529pzk.28 for ; Mon, 10 May 2010 10:47:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=nI9HhhpKB1qQ/dhCSVswOIxWQS2MikvNxyio7WCu110=; b=qWZ7K/JsV79Xc61uRKNhxBKB9kltzOdNtGFNHjGAnEWWJP2NGRsIiv8rawZm3AO1lA HKJWRTNeIOV0trGdFIjoOe+AUJLB7SdOC3+VOKdbhJmV0LRuNR7bBcnV3anJjsbsbcIN 7dSyyyo+HXYBFFGI0Y9DYcy5CiiOP2QZxhTiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=t+mSTAWv4BEYa7RuN65bFvKKlEH1wvhmz58zbxUw5Q1kKHaofWMFJFV1EYQI6HZi9y kwZ1jms52+WieipMK5LQs/o5LzXYX9OuA3Wl0SIaAKsAmJNrsnwOZ9n8Nh0Z4CvqNq/O S6CDrY0V9o/Wq8go8mSQgBgschqZAX8viyqms= Received: by 10.140.179.20 with SMTP id b20mr2801694rvf.246.1273513633174; Mon, 10 May 2010 10:47:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.133.10 with HTTP; Mon, 10 May 2010 10:46:53 -0700 (PDT) In-Reply-To: <4BE7E62C02000025000314B7@gw.wicourts.gov> References: <4BE81CA1.4080201@partiallystapled.com> <201005101512.o4AFCZS27089@momjian.us> <4BE7E62C02000025000314B7@gw.wicourts.gov> From: Greg Stark Date: Mon, 10 May 2010 18:46:53 +0100 X-Google-Sender-Auth: 42d5fb62804c9fc3 Message-ID: Subject: Re: no universally correct setting for fsync To: Kevin Grittner Cc: Robert Haas , Bruce Momjian , Michael Tharp , pgsql-hackers@postgresql.org, Craig Ringer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201005/475 X-Sequence-Number: 162138 On Mon, May 10, 2010 at 4:55 PM, Kevin Grittner wrote: > Robert Haas wrote: > >> "It might be safe" is a bit of a waffle. =A0It would be nice if we >> could provide some more clear guidance as to whether it is or is >> not, or how someone could go about testing their hardware to find >> out. > > I think that the issue is that you could have corruption if some, > but not all, disk sectors from a page were written from OS cache to > controller cache when a failure occurred. =A0The window would be small > for a RAM-to-RAM write, but it wouldn't be entirely *safe* unless > there's some OS/driver environment where you could count on all the > sectors making it or none of them making it for every single page. > Does such an environment exist? The reason for the waffle is that the following sentence describes a whole set of environments based the following description: > > ? ? ? ?if you have hardware (such as a battery-backed > > ? ? ? ?disk controller) or file-system software that reduces the risk > > ? ? ? ?of partial page writes to an acceptably low level Depending on which set of hardware and how low the risk is it might be safe= . I think with WAFL or ZFS it's entirely safe. There may be other filesystems with similar guarantees. With a BBU the risk might be very low -- but it might not, it would be hard to determine without a detailed analysis of the entire stack from the buffer cache, filesystem, lvm, hardware drivers, BBU design, etc. --=20 greg