Re: Patch to improve reliability of postgresql on linux nfs
От | Tom Lane |
---|---|
Тема | Re: Patch to improve reliability of postgresql on linux nfs |
Дата | |
Msg-id | 11092.1315578442@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Patch to improve reliability of postgresql on linux nfs (George Barnett <gbarnett@atlassian.com>) |
Ответы |
Re: Patch to improve reliability of postgresql on linux nfs
Re: Patch to improve reliability of postgresql on linux nfs Re: Patch to improve reliability of postgresql on linux nfs |
Список | pgsql-hackers |
George Barnett <gbarnett@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
В списке pgsql-hackers по дате отправления: