| From: | Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> |
|---|---|
| To: | Greg Stark <gsstark(at)mit(dot)edu> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: EINTR error in SunOS |
| Date: | 2005-12-31 21:46:02 |
| Message-ID: | Pine.LNX.4.58.0512311639270.8011@eon.cs |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, 31 Dec 2005, Greg Stark wrote:
>
> I don't think that's reasonable. The NFS intr option breaks the traditional
> unix filesystem semantics which breaks a lot of older or naive programs. But
> that's no reason to decide that Postgres can't handle the new semantics.
>
Is that by default the EINTR is truned off in NFS? If so, I don't see that
will be a problem. Sorry for my limited knowledge, is there any
requirements/benefits that people turn on EINTR?
> Handling EINTR after all file system calls doesn't sound like it would be
> terribly hard.
The problem is not restricted to file system. Actually my patched
version(only backend/storage) passed hundreds times of regression without
any problem, but EINTR can hurt other syscalls as well. Find out *all* the
EINTR situtations may need big efforts AFAICS.
Regards,
Qingqing
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Martijn van Oosterhout | 2005-12-31 21:50:49 | Re: EINTR error in SunOS |
| Previous Message | Greg Stark | 2005-12-31 20:56:59 | Re: EINTR error in SunOS |