Tom Lane wrote:
> George Barnett <gbarn...@atlassian.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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
