Re: Fwd: Re: A new look at old NFS readdir() problems? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Fwd: Re: A new look at old NFS readdir() problems?
Date
Msg-id 309402.1735854754@sss.pgh.pa.us
Whole thread Raw
In response to Re: Fwd: Re: A new look at old NFS readdir() problems?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Fwd: Re: A new look at old NFS readdir() problems?
Re: Fwd: Re: A new look at old NFS readdir() problems?
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Thu, Jan 2, 2025 at 3:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm still of the opinion that the best thing to do is disclaim
>> safety of storing a database on NFS.

> If we're going to disclaim support for NFS, it would certainly be
> better to do that clearly and with reasons than otherwise. However, I
> suspect a substantial number of users will still use NFS and then
> blame us when it doesn't work; or alternatively say that our software
> sucks because it doesn't work on NFS. Neither of which are very nice
> outcomes.

Are you prepared to buy into "we will make every bit of code that uses
readdir() proof against arbitrary lies from readdir()"?  I'm not:
I cannot see how to do that in any but the simplest cases -- rmtree()
being about the simplest.  Even if we had a bulletproof design in
mind, it's pretty hard to believe that future patches would apply
it every time.  I think it's inevitable that we'd have bugs like
"sometimes not every file gets fsync'd", which would be impossible
to find until someone's data gets eaten, and maybe still impossible
to find afterwards.

(To be clear: if this is how FreeBSD acts, then I'm afraid we already
do have such bugs.  The rmtree case is just easier to observe than a
missed fsync.)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Alias of VALUES RTE in explain plan
Next
From: Tom Lane
Date:
Subject: Re: magical eref alias names