Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 52C5964FCEC for ; Mon, 8 Sep 2008 11:59:11 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 36785-06 for ; Mon, 8 Sep 2008 11:59:08 -0300 (ADT) X-Greylist: delayed 00:42:16.528314 by SQLgrey-1.7.6 Received: from gv-out-0910.google.com (gv-out-0910.google.com [216.239.58.189]) by postgresql.org (Postfix) with ESMTP id D5E7C64FCE6 for ; Mon, 8 Sep 2008 11:59:07 -0300 (ADT) Received: by gv-out-0910.google.com with SMTP id i36so203876gve.7 for ; Mon, 08 Sep 2008 07:59:06 -0700 (PDT) Received: by 10.210.118.7 with SMTP id q7mr18885887ebc.197.1220885946046; Mon, 08 Sep 2008 07:59:06 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ( [82.16.16.210]) by mx.google.com with ESMTPS id t2sm8150996gve.9.2008.09.08.07.59.04 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 08 Sep 2008 07:59:05 -0700 (PDT) To: "Nikolas Everett" Cc: "Bruce Momjian" , pgsql-performance@postgresql.org Subject: Re: SAN and full_page_writes In-Reply-To: (Nikolas Everett's message of "Mon\, 8 Sep 2008 10\:48\:21 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:PG" 2002) References: <200809061946.m86JkeS01341@momjian.us> <87myii4t9o.fsf@oxford.xeocode.com> From: Gregory Stark Organization: EnterpriseDB Date: Mon, 08 Sep 2008 15:59:03 +0100 Message-ID: <873aka4rbc.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200809/86 X-Sequence-Number: 31399 "Nikolas Everett" writes: > Sounds kind of scary. I think postgres forces the underlying OS and file > system to do that stuff (sans the mutli-host magic) using fsync. Is that > right? Yes, so you have to make sure that your filesystem really does support fsync properly. I think most NFS implementations do that. I was more concerned with: Network Appliance supports a number of NFS client implementations for u= se with databases. These clients provide write atomicity to at least 4 KB, and support synchronous writes when requested by the database. Typicall= y, atomicity is guaranteed only to one virtual memory page, which may be as small as 4 KB. However, if the NFS client supports a direct I/O mode th= at completely bypasses the cache, then atomicity is guaranteed to the size specified by the =93wsize=94 mount option, typically 32 KB. The failure of some NFS clients to assure write atomicity to a full database block means that the soft atomicity requirement is not always met. Some failures of the host system may result in a fractured database block on disk. In practice such failures are rare. When they happen no data is lost, but media recovery of the affected database block may be required That "media recovery" it's referring to sounds like precisely our WAL full page writes... --=20 Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support!