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

Re: Patch to improve reliability of postgresql on linux nfs

From: Peter Eisentraut <peter_e(at)gmx(dot)net>
To: George Barnett <gbarnett(at)atlassian(dot)com>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, Bernd Helmle <mailings(at)oopsware(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Date: 2011-09-12 12:54:39
Message-ID: 1315832079.5351.5.camel@fsopti579.F-Secure.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On mån, 2011-09-12 at 16:46 +1000, George Barnett wrote:
> On 12/09/2011, at 3:59 PM, Florian Pflug wrote:
> 
> > If you really meant to say "intr" there (and not "nointr") then that probably explains the partial writes.
> > 
> > Still, I agree with Noah and Kevin that we ought to deal more gracefully with this, i.e. resubmit after a partial read() or write(). AFAICS there's nothing to be gained by not doing that, and the increase in code complexity should be negligible. If we do that, however, I believe we might as well handle EINTR correctly, even if SA_RESTART should prevent us from ever seeing that.
> 
> 
> Hi Florian,
> 
> You are indeed correct.  Setting nointr also resolves my issue.  I could swear I checked this, but obviously not.
> 
> It does still concern me that pgsql did not deal with this as gracefully as other software.  I hope the list will consider a patch to resolve that.

We have signal handling configured so that system calls are not
interrupted.  So there is ordinarily no reason to do anything more
graceful.  The problem is that NFS is in this case not observing that
setting.  It's debatable whether it's worth supporting that; just saying
that the code is correct as it stands.



In response to

Responses

pgsql-hackers by date

Next:From: ktm@rice.eduDate: 2011-09-12 12:54:52
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Previous:From: Peter EisentrautDate: 2011-09-12 12:39:42
Subject: Re: psql additions

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