Skip site navigation (1) Skip section navigation (2)

Re: EINTR error in SunOS

From: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: EINTR error in SunOS
Date: 2006-01-01 06:54:49
Message-ID: dp7u9i$2idq$ (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Greg Stark" <gsstark(at)mit(dot)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?


In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2006-01-01 07:36:22
Subject: Re: EINTR error in SunOS
Previous:From: Bruce MomjianDate: 2006-01-01 04:18:48
Subject: Checks for command string

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group