Skip site navigation (1) Skip section navigation (2)

Re: Patch to improve reliability of postgresql on linux nfs

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: George Barnett <gbarnett(at)atlassian(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Date: 2011-09-09 23:06:49
Message-ID: 201109092306.p89N6n904631@momjian.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Tom Lane wrote:
> George Barnett <gbarnett(at)atlassian(dot)com> writes:
> > [ patch to retry writes on NFS ]
> 
> I'm having a hard time getting excited about this idea, because IMO
> NFS is insufficiently reliable to run a database on, and no patch like
> this can fix that.  However, some concrete points:
> 
> 1. If writes need to be retried, why not reads?  (No, that's not an
> invitation to expand the scope of the patch; it's a question about NFS
> implementation.)
> 
> 2. What is the rationale for supposing that a retry a nanosecond later
> will help?  If it will help, why didn't the kernel just do that?
> 
> 3. What about EINTR?  If you believe that this is necessary, then the
> kernel logically has to return EINTR when it would like you to retry but
> it hasn't been able to write any bytes yet.  If you get a zero return
> you have to assume that means out-of-disk-space.
> 
> 4. As coded, the patch behaves incorrectly if you get a zero return on a
> retry.  If we were going to do this, I think we'd need to absorb the
> errno-munging currently done by callers into the writeAll function.
> 
> On the whole I think you'd be better off lobbying your NFS implementors
> to provide something closer to the behavior of every other filesystem on
> the planet.  Or checking to see if you need to adjust your NFS
> configuration, as the other responders mentioned.

Can our NFS documentation be improved (section 17.2.1)?

	http://www.postgresql.org/docs/9.1/static/creating-cluster.html

-- 
  Bruce Momjian  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +

In response to

pgsql-hackers by date

Next:From: Greg StarkDate: 2011-09-09 23:07:28
Subject: Re: unite recovery.conf and postgresql.conf
Previous:From: Greg StarkDate: 2011-09-09 22:54:18
Subject: Re: Large C files

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group