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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
