On 2/19/19 5:20 PM, Robert Haas wrote:
> On Tue, Feb 19, 2019 at 10:59 AM Magnus Hagander <magnus@hagander.net> wrote:
>> The only case I've run into people wanting to use postgres on NFS,
>> the NFS server is a big filer from netapp or hitachi or whomever. And
>> you're not going to be able to run something like that on top of it.
>
> Yeah. :-(
>
> It seems, however, we have no way of knowing to what extent that big
> filer actually implements the latest NFS specs and does so correctly.
> And if it doesn't, and data goes down the tubes, people are going to
> blame PostgreSQL, not the big filer, either because they really
> believe we ought to be able to handle it, or because they know that
> filing a trouble ticket with NetApp isn't likely to provoke any sort
> of swift response. If PostgreSQL itself is speaking NFS, we might at
> least have a little more information about what behavior the filer
> claims to implement, but even then it could easily be "lying." And if
> we're just seeing it as a filesystem mount, then we're just ... flying
> blind.
>
Perhaps we should have something like pg_test_nfs, then?
>> There might be a use-case for the split that you mention,
>> absolutely, but it's not going to solve the people-who-want-NFS
>> situation. You'd solve more of that by having the middle layer
>> speak "raw device" underneath and be able to sit on top of things
>> like iSCSI (yes, really).
>
> Not sure I follow this part.
>
I think Magnus says that people running PostgreSQL on NFS generally
don't do that because they somehow chose NFS, but because that's what
their company uses for network storage. Even if we support the custom
block protocol, they probably won't be able to use it.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services