Re: EINTR error in SunOS
От | Qingqing Zhou |
---|---|
Тема | Re: EINTR error in SunOS |
Дата | |
Msg-id | dp7u9i$2idq$1@news.hub.org обсуждение исходный текст |
Ответ на | EINTR error in SunOS (Qingqing Zhou <zhouqq@cs.toronto.edu>) |
Ответы |
Re: EINTR error in SunOS
|
Список | pgsql-hackers |
"Greg Stark" <gsstark@mit.edu> wrote > > Well NFS is only going to affect filesystem calls. If there are other > syscalls > that can signal EINTR on some obscure platform where Postgres isn't > handling > it then that's just a run-of-the-mill porting issue. > Ok, NFS just affects filesystem calls(I mix it with another problem). If possible, I hope we can draw some conclusion / schetch a fix plan here for future developers who want to come up with a patch. The question is: Where and how should we fix exactly in order to incorporate intr NFS in server side? More details we write down here, more feasible/infeasible plan we can get. I could think of these places: + direct file system calls - open() family, fopen() family in backend/storage - scattered open() etc in the whole backend(seems unlink is with biggest problem) The problem of above is if a signal sneaks in, these syscalls will fail. With a retry, we can fix it. + indirect file system calls - system("xxx") calls, xxx = cp, etc. If intr NFS is enabled, what's the problem exactly? Any others? Regards, Qingqing
В списке pgsql-hackers по дате отправления: