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
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 |