Subject: Re: PG on NFS may be just a bad idea
From: Simon Riggs <simon@2ndquadrant.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Josh Berkus <josh@agliodbs.com>, pgsql-hackers@postgresql.org,
	Mija Lee <mija@scharp.org>
In-Reply-To: <24184.1191281116@sss.pgh.pa.us>
References: <25517.1191038302@sss.pgh.pa.us> <47012AC5.9040808@agliodbs.com>
	<1191263814.4260.57.camel@ebony.site>
	<1191264888.4260.69.camel@ebony.site>
	<24184.1191281116@sss.pgh.pa.us>
Content-Type: text/plain
Date: Tue, 09 Oct 2007 08:44:21 +0100
Message-Id: <1191915861.4223.601.camel@ebony.site>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit

On Mon, 2007-10-01 at 19:25 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> writes:
> > http://blogs.netapp.com/dave/2007/08/oracle-optimize.html
> 
> Not a whole lot of technical content there, but pretty interesting
> nonetheless.  I *think* that the issues we're seeing are largely in the
> NFS client-side kernel code, so bypassing that stack as Oracle is doing
> might eliminate the problem.  Of course, there's a sizable amount of
> code to be written to do that ...

Yeh, that would take a while.

I thought of another reason to do that also.

If you put a tablespace on an NFS mount and the remote server crashes,
it sounds like there could be a window of potential data loss. We could
guard against that by recovering the tablespace, but we don't do that
unless the local server crashes. 

So having your own NFS client would allow you to tell that the link had
dropped and needed to be recovered.

-- 
  Simon Riggs
  2ndQuadrant  http://www.2ndQuadrant.com