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 по дате отправления: