Hacker News Reader

Comment by dboreham | Hacker News Reader

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.

View on HN

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.

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.

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".

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.

Reply on news.ycombinator.com