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: 87wthl6l44.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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.

--
greg

In response to

Responses

Browse pgsql-hackers by date

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