Re: [PERFORM] SAN and full_page_writes

"Nikolas Everett" <nik9000@gmail.com> 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 use
with databases. These clients provide write atomicity to at least 4 KB,
and support synchronous writes when requested by the database. Typically,
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 that
completely bypasses the cache, then atomicity is guaranteed to the size
specified by the "wsize" 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...

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance