Search Postgresql Archives

Re: "make check" fails over NFS or tmpfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2006-05-22 at 10:25, Greg Stark wrote:
> Using TCP with NFS is only really helpful when you have a high latency high
> bandwidth link which isn't going to be a terribly positive environment for
> postgres.
> 

Well, having a protocol that by definition says that datagrams may
arrive out of order or go missing without notice does not sound like a
good thing to have a database running on.

[.......]
> environment. But the others shouldn't be terribly relevant -- hell, bg only
> affects the actual mount operation.
> 

The result of using cut & paste ;) not directly relevant to postgres but
nice to have when mounting the nfs directory. 

> While I'm leery about recommending any network filesystem for anything that
> depends on the filesystem as heavily as a database, of all the network
> filesystems NFS takes the most care to maintain solid semantics. The main
> problem is that people are always looking for new and interesting ways to
> defeat those semantics with options like soft mounts. Certainly I can't agree
> with "anything is better than NFS", what would you recommend, samba?
> 

Samba? :-) not at all, it was a way of saying how bad idea is to run a
database via NFS if you want reliability and performance. Not everybody
agrees with this, but well, they can do what the want with their data.

> 
> "async" "intr" and "soft" seem like the real foot-guns here. 

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. 

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.

-- 
Rafael Martinez, <r.m.guerrero@xxxxxxxxxxx>
Center for Information Technology Services
University of Oslo, Norway

PGP Public Key: http://folk.uio.no/rafael/



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux