Re: EINTR error in SunOS
От | Qingqing Zhou |
---|---|
Тема | Re: EINTR error in SunOS |
Дата | |
Msg-id | Pine.LNX.4.58.0512302008440.31458@eon.cs обсуждение исходный текст |
Ответ на | Re: EINTR error in SunOS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: EINTR error in SunOS
|
Список | pgsql-hackers |
On Fri, 30 Dec 2005, Tom Lane wrote: > > I've heard of this in connection with NFS ... is your DB on an NFS > filesystem by any chance? > I have patched IO routines in backend/storage that POSIX says EINTR is possible except unlink(). Though POSIX says EINTR is not possible, during many regressions, I found it sometimes sets this errno on NFS (I still don't know where is the smoking-gun): TRUNCATE TABLE trunc_c,trunc_d,trunc_e; -- ok + WARNING: could not remove relation 1663/16384/37822: Interrupted system call There are many other unlink() scattered in backend, some even without error check. Shall we patch pg_unlink for this situation and replace them like this: pg_unlink(const char* path, int errlevel){ retry: returnCode = unlink(path); if (returnCode < 0 && errno==EINTR) goto retry; if other_errors elog(elevel, ...); return returnCode;} Or pg_unlink(const char* path){ /* no elog -- but we still have to do error check */} Or let it be ... If we decide to do something for unlink(), then we'd better do something for other EINTR-possible IO routines for fairness :-) By the way, seems POSIX is not very consistent with EINTR. For example, closedir() can set EINTR, but opendir()/readdir() can't. Any magic in it? Regards, Qingqing
В списке pgsql-hackers по дате отправления: