Re: The case of PostgreSQL on NFS Server - Mailing list pgsql-general

From Craig Ringer
Subject Re: The case of PostgreSQL on NFS Server
Date
Msg-id 4C2302AD.6020009@postnewspapers.com.au
Whole thread Raw
In response to The case of PostgreSQL on NFS Server  (Iwao Shikase <shikase@air.co.jp>)
Responses Re: The case of PostgreSQL on NFS Server
Re: The case of PostgreSQL on NFS Server
List pgsql-general
On 24/06/10 12:42, Iwao Shikase wrote:

> In my environment, Database cluster is in NFS server.

So you are mounting an nfs file system shared by "localhost" ?

Why not run PostgreSQL directly on the underlying file system, rather
than via nfs?

> I guess that, In my environment,  the mount options, system synchronously
> and without cache does not need.

I would still expect to lose some written data if the system crashed or
lost power and nfs write caching was enabled. Because nfs's caching
doesn't guarantee write ordering, this data loss would probably horribly
corrupt your database.

If you can get your NFS implementation to guarantee write ordering then
it's quite safe to cache. Good luck proving that it's doing the right
thing, though.

Even if you're certain it's correct, you need to do a lot of testing
where you abuse the server and see how it copes. Unplug it unexpectedly.
Press the reset switch. 'kill -9' the backends. Crash the operating
system. Etc. See if there's any sign of damage to the PostgreSQL storage
after repeated abuse of the server like that.

> If I mount the database cluster with caching in my environment, What kind of
>  problem I will meet? Please give the information about the problem you met.

It varies so much by NFS implementation and version that it is really
hard to say.

Personally, I would never, EVER run a database of any kind over nfs, but
perhaps I'm just scarred by Linux's NFS implementation.

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

pgsql-general by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Global temporary table - schema
Next
From: Karsten Hilbert
Date:
Subject: Re: copy/duplicate database schemas