Re: "make check" fails over NFS or tmpfs

From: Greg Stark <gsstark(at)mit(dot)edu>
To: "Rafael Martinez, Guerrero" <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, SODA Noriyuki <soda(at)sra(dot)co(dot)jp>, pgsql-general(at)postgresql(dot)org, takuya(at)soum(dot)co(dot)jp
Subject: Re: "make check" fails over NFS or tmpfs
Date: 2006-05-22 16:52:33
Message-ID: 87veryknn2.fsf@stark.xeocode.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

"Rafael Martinez, Guerrero" <r(dot)m(dot)guerrero(at)usit(dot)uio(dot)no> writes:

> Why do you think 'intr' is a bad thing, from man pages:
> " ........ If an NFS file operation has a major timeout and it is
> hard mounted, then allow signals to interupt the file operation and
> cause it to return EINTR to the calling program. The default is to not
> allow file operations to be interrupted ....."
>
> This will be like an error reported by the filesystem, the program will
> get the information and will take care of the problem instead of waiting
> indefinitely for a respons not comming and having the database probably
> in a nonconsistent state.

Traditional file systems guaranteed it never happened, so older applications
do not expect to have filesystem operations interrupted. Many do not check for
it or do not handle it properly. I recall a conversation a while back about
Postgres in particular not checking for it.

> With 'noac' I was thinking about two processes trying to access the same
> file at the same time, better not to have some cache in our way that
> alter the real state of the file to other processes.

The description of the option gave me the impression that this would only be
an issue if your processes were on two different clients.

--
greg

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Schmidt 2006-05-22 17:20:04 Changes in pl/pgsql?
Previous Message Dawid Kuroczko 2006-05-22 16:13:26 Re: project