From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: EINTR error in SunOS |
Date: | 2005-12-31 01:25:05 |
Message-ID: | Pine.LNX.4.58.0512302008440.31458@eon.cs |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-12-31 05:58:19 | Re: Removing SORTFUNC_LT/REVLT |
Previous Message | Sebastian | 2005-12-30 23:46:09 | Re: broken 'SHOW TABLE'-like query works in 8, not 8.1.1 |