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

Re: EINTR error in SunOS

From: Doug Royer <Doug(at)Royer(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: EINTR error in SunOS
Date: 2006-01-01 00:31:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
EINTR on read() or write() is not unique to NFS.
It can happen on many file systems - it is just seen
less frequently on most of them.

The code should be able to handle ANY valid read()
and write() errno. And EINTR is documented on Linux, BSD,
Solaris (1 and 2), and POSIX.

Even the Linux man pages can return ENTER on read() and
write(). This can happen on soft-mirrors, SCSI disks, and SOME
other disk drivers when they have errors.

The 'intr' option to NFS is not the same as EINTR. It
it means 'if the server does not respond for a while,
then return an EINTR', just like any other disk read()
or write() does when it fails to reply.

I have seen lots of open source code that assumes that all
disk reads and writs work 100% or fail 100%. Many do not
check the return value to see if all data was written or
read from disk. And many do not look at errno at all.
I have NOT looked to see how postgres does it.

If storage/*.c is where the reads occur, it does
very LITTLE when checking for errors.

>>>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.
> 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.
> But like I mentioned in the other thread POSIX is of no help here. With the
> exception of the pthreads syscalls POSIX doesn't prohibit functions from
> signalling errors other than the ones documented in the specification. So in
> other words, just about any function can signal just about any error including
> errors that are proprietary additions any time. Good luck :)


Doug Royer                     |

               We Do Standards - You Need Standards

In response to


pgsql-hackers by date

Next:From: August ZajoncDate: 2006-01-01 01:02:24
Subject: Re: [Bizgres-general] WAL bypass for INSERT, UPDATE and
Previous:From: Tom LaneDate: 2006-01-01 00:04:42
Subject: Re: [PATCHES] default resource limits

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