pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Nikolas Everett <nik9000@gmail.com>
To: Gregory Stark <stark@enterprisedb.com>
Cc: Bruce Momjian <bruce@momjian.us>
Cc: pgsql-performance@postgresql.org
Subject: Re: SAN and full_page_writes
Date: Mon, 8 Sep 2008 10:48:21 -0400
Message-ID: <d4e11e980809080748k6f647b6cue9d202f8feb9abca@mail.gmail.com> (raw)
In-Reply-To: <87myii4t9o.fsf@oxford.xeocode.com>
References: <d4e11e980809050724m5f0e8971n3909c26026fda47b@mail.gmail.com>
	<200809061946.m86JkeS01341@momjian.us>
	<d4e11e980809080702i629187bbqab5dd70581ee8057@mail.gmail.com>
	<87myii4t9o.fsf@oxford.xeocode.com>

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@enterprisedb.com>wrote:

>
> "Nikolas Everett" <nik9000@gmail.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!
>

view thread (9+ messages)  latest in thread

Message-ID: <d4e11e980809080748k6f647b6cue9d202f8feb9abca@mail.gmail.com>
Permalink:  ../d4e11e980809080748k6f647b6cue9d202f8feb9abca@mail.gmail.com/
Also on:    postgresql.org/message-id/d4e11e980809080748k6f647b6cue9d202f8feb9abca@mail.gmail.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: nik9000@gmail.com, stark@enterprisedb.com, bruce@momjian.us
  Subject: Re: SAN and full_page_writes
  In-Reply-To: <d4e11e980809080748k6f647b6cue9d202f8feb9abca@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox