Comment by dboreham
7 years ago
In case someone reads this and gets the impression that running PG over NFS is in general safe or a good idea, I'm pretty sure it still isn't, unless like the OP you have a complete understanding of what you're doing.
7 years ago
In case someone reads this and gets the impression that running PG over NFS is in general safe or a good idea, I'm pretty sure it still isn't, unless like the OP you have a complete understanding of what you're doing.
I have quite successfully run pg atop NFS — even, in limited, point-solution type roles, in production. My experience doing that didn't leave me with the impression that it was a particularly egregious thing to do, though I would definitely take many, many additional steps to ensure redundancy and availability if I were going to use it more generally.
You're right though: you really do want to have some idea what you're doing, if you're going to go there.
Source: my day job is PostgreSQL DBA, and has been for ~15 years now.
EDIT: Phrasing.
I think the problem is mostly ENOSPC from fsync() which jettisons data just like EIO on Linux. If you ran out of space, PostgreSQL would only learn about that while checkpointing, and then retry and carry on. Boom, data loss. Today PostgreSQL would panic on the first ENOSPC from fsync() so the problem is mostly "fixed".
The main thing to keep in mind is that NFS exercises a bunch of VFS code paths that effectively no other filesystems touches. So you are more at risk to strange VFS bugs, as well as general NFS shenanigans, which other PG users may not have seen before.
OT: it depends on how much writes/reads you get. for most people nfs is probably an easier solution for HA on postgres than anything else.
That’s pretty much computing. It’s usually the case that unless you have a complete understanding, there’s a pothole waiting to trip you.
As an FYI - we no longer use Postgres on NFS as we have migrated the entire architecture underlying the systems in question.