On Tue, Feb 19, 2019 at 2:03 AM Thomas Munro <thomas.mu...@gmail.com> wrote: > How can we achieve that, without writing our > own NFS client?
<dons crash helmet> Instead of writing our own NFS client, how about writing our own network storage protocol? Imagine a stripped-down postmaster process running on the NFS server that essentially acts as a block server. Through some sort of network chatter, it can exchange blocks with the real postmaster running someplace else. The mini-protocol would contain commands like READ_BLOCK, WRITE_BLOCK, EXTEND_RELATION, FSYNC_SEGMENT, etc. - basically whatever the relevant operations at the smgr layer are. And the user would see the remote server as a tablespace mapped to a special smgr. As compared with your proposal, this has both advantages and disadvantages. The main advantage is that we aren't dependent on being able to make NFS behave in any particular way; indeed, this type of solution could be used not only to work around problems with NFS, but also problems with any other network filesystem. We get to reuse all of the work we've done to try to make local operation reliable; the remote server can run the same code that would be run locally whenever the master tells it to do so. And you can even imagine trying to push more work to the remote side in some future version of the protocol. The main disadvantage is that it doesn't help unless you can actually run software on the remote box. If the only access you have to the remote side is that it exposes an NFS interface, then this sort of thing is useless. And that's probably a pretty common scenario. So that brings us back to your proposal. I don't know whether there's anyway of solving the problem you postulate: "We need the server and NFS client and libc to be of the right version and cooperate and tell us that they have really truly reserved space." If there's not a set of APIs that can be used to make that happen, then I don't know how we can ever solve this problem without writing our own client. Well, I guess we could submit patches to every libc in the world to add those APIs. But that seems like a painful way forward. I'm kinda glad you're thinking about this problem because I think the unreliably of PostgreSQL on NFS is a real problem for users and kind of a black eye for the project. However, I am not sure that I see an easy solution in what you wrote, or in general. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
