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

Re: Patch to improve reliability of postgresql on linux nfs

From: Florian Pflug <fgp(at)phlo(dot)org>
To: "ktm(at)rice(dot)edu" <ktm(at)rice(dot)edu>
Cc: George Barnett <gbarnett(at)atlassian(dot)com>, 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 13:39:02
Message-ID: 92B997F7-92DF-4B6C-84EC-8A81709C3A2F@phlo.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sep12, 2011, at 14:54 , ktm(at)rice(dot)edu wrote:
> Many, many, many other software packages expect I/O usage to be the same on
> an NFS volume and a local disk volume, including Oracle. Coding every application,
> or more likely mis-coding, to handle this gives every application another chance
> to get it wrong. If the OS does this, when it gets it right, all of the apps get
> it right. I think you should be surprised when other software actually deals with
> broken I/O semantics gracefully rather than concerned when one of a pantheon of
> programs does not. My two cents.

I don't buy that. People seem to be perfectly able to code correct networking
applications (correct from a read/write API POV at least), yet those applications
need to deal with partial reads and writes too.

Really, it's not *that* hard to put a retry loop around "read" and "write".

Also, non-interruptible IO primitives are by no means "right". At best, they're
a compromise between complexity and functionality for I/O devices with rather
short (and bounded) communication timeouts - because in that case, processes are
only blocked un-interruptibly for a short while.

best regards,
Florian Pflug


In response to

Responses

pgsql-hackers by date

Next:From: Josh BerkusDate: 2011-09-12 13:46:52
Subject: Re: Alpha 1 for 9.2
Previous:From: Florian PflugDate: 2011-09-12 13:27:00
Subject: Re: Patch to improve reliability of postgresql on linux nfs

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