Hi all, This has been discussed before (some URLs below), but the threads have unfortunately been rather free of (precise) information. I am interested in getting PG running over NFS. However, I am primarily concerned with safety/recoverability (on sudden power loss); I care very, very little about the performance. Hence, I think this is a substantially simpler question to answer definitively (must also assume the NFS server may lose power). The particular NFS client and server implementations I'm using are the Linux NFS implementation (using kernel 2.6). If PG is unsuitable for this task, can any (preferrably open-source) alternatives be recommended? (Just for curiosity, consider any storage system supporting transactions and recovery, not necessarily the relational model or high performance.) BTW I've included some correspondence from my colleagues; I would also appreciate it if any corrections are offered to their statements (if necessary). From querying #postgresql on FreeNode, I gathered that as long as fsync works properly (flushes data to the server), there are no other concerns (and that there is in fact no file locking, except perhaps on the pid file). Thanks a lot! Yang http://archives.postgresql.org/pgsql-performance/2004-06/msg00215.php http://www.thescripts.com/forum/thread422520.html http://lists.freebsd.org/pipermail/freebsd-database/2006-January/000372.html
Hmm... that's bad. The memory mapped IO we can live without (sure, it's a performance issue, but at least it'll probably still work). Mutexes and locks... I wonder if we could put them in a ramdrive? > It is not recommended to place database storage onto NFS. This is > seems to be true for Postgresql, SQLite, and BerkleyDB, it seems that > this is a general problem. The reasons are: > * DBs use memory mapped IO > * DBs use mutexes and locks > > Presumably, neither of these work over NFS. I don't have any hard > evidence, I just read a bunch of FAQs and messages on mailings lists. > If this is indeed the case, that pretty much kills our plan for > hosting a DB on the slave. The "no,no" alternative is to place the DB > server on the master... and that would only work out of the box for > non-embedded databases.
