Re: Patch to improve reliability of postgresql on linux nfs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Aidan Van Dyk <aidan(at)highrise(dot)ca>, George Barnett <gbarnett(at)atlassian(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Patch to improve reliability of postgresql on linux nfs
Date: 2011-09-13 14:25:15
Message-ID: 5314.1315923915@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> writes:
> On Sep13, 2011, at 15:05 , Aidan Van Dyk wrote:
>> Personally, I'ld think that's ripe for bugs. If the contract is that
>> ret != amount is the "error" case, then don't return -1 for an error
>> *sometimes*.

> Hm, but isn't that how write() works also?

Yeah. It's not possible to maintain the same error-reporting contract
that bare write() has got, unless you're willing to forget about actual
errors reported by a non-first write attempt. Which might not be
totally unreasonable, because presumably something similar is going on
under the hood within write() itself. Most of the errors one might
think are worth reporting would have had to occur on the first write
attempt anyway.

But if you do want to report such errors, I think you have to push the
error reporting logic into the subroutine, which seems a bit messy since
there's quite a variety of error message phrasings out there, all of
which require information that write() itself does not have. Also, we
do *not* want e.g. gettext() to be invoked unless an error actually
occurs and has to be reported.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-09-13 14:27:08 Re: augmenting MultiXacts to improve foreign keys
Previous Message Tom Lane 2011-09-13 14:17:20 Re: SSL key with passphrase