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

Re: EINTR error in SunOS

From: Greg Stark <gsstark(at)mit(dot)edu>
To: Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: EINTR error in SunOS
Date: 2005-12-31 20:56:59
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Qingqing Zhou <zhouqq(at)cs(dot)toronto(dot)edu> writes:

> On Sat, 31 Dec 2005, Tom Lane wrote:
> >
> > What I'd rather do is document prominently that running a DB over NFS
> > isn't recommended, and running it over NFS with interrupts allowed is
> > just not going to work.
> Agreed. IO syscalls is not the only problem for NFS -- if we can't fix
> them in a run, then don't do it.

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.

Handling EINTR after all file system calls doesn't sound like it would be
terribly hard. And Postgres of all systems has the infrastructure necessary to
handle error conditions, abort and roll back the transaction when a file
system error occurs. I think mainly this means it would be possible to hit C-c
or shut down postgres (uncleanly) when there's a network outage.


In response to


pgsql-hackers by date

Next:From: Qingqing ZhouDate: 2005-12-31 21:46:02
Subject: Re: EINTR error in SunOS
Previous:From: Martijn van OosterhoutDate: 2005-12-31 20:56:30
Subject: Re: Removing SORTFUNC_LT/REVLT

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