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

Re: Patch to improve reliability of postgresql on linux nfs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: George Barnett <gbarnett(at)atlassian(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Date: 2011-09-09 14:27:22
Message-ID: 11092.1315578442@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Alexey KlyukinDate: 2011-09-09 15:17:04
Subject: Re: REVIEW proposal: a validator for configuration files
Previous:From: Tom LaneDate: 2011-09-09 14:08:46
Subject: Re: WAL "low watermark" during base backup

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