Re: SAN and full_page_writes

Sorry about that. I was having tunnel vision and pulled out the part that
applied to me. I also figured that the OS and file system information was
superfluous but on second look it may not be. This bit:

To satisfy the Durability requirement, all write operations must write
through any OS
cache to stable storage before they are reported as complete or otherwise
made visible.
Write-back caching behavior is prohibited, and data from failed writes must
not appear in
an OS cache.
To satisfy the Serialization requirements, any OS cache must be fully
coherent with the
underlying storage. For instance, each write must invalidate any OS-cached
copies of
the data to be overwritten, on any and all hosts, prior to commitment.
Multiple hosts may
access the same storage concurrently under shared-disk clustering, such as
that
implemented by Oracle RAC and/or ASM.

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?

It does look like there are some gotchas with NFS.

On Mon, Sep 8, 2008 at 10:16 AM, Gregory Stark <stark(at)enterprisedb(dot)com>wrote:

>
> "Nikolas Everett" <nik9000(at)gmail(dot)com> writes:
>
> > Thanks for pointing that out Bruce.
> >
> > NetApp has a 6 page PDF about NetApp and databases. On page 4:
>
> Skimming through this I think all 6 pages are critical. The sentence you
> quote
> out of context pertains specifically to the NAS internal organization.
>
> The previous pages discuss limitations of OSes, filesystems and especially
> NFS
> clients which you may have to be concerned with as well.
>
> --
> Gregory Stark
> EnterpriseDB http://www.enterprisedb.com
> Ask me about EnterpriseDB's Slony Replication support!
>