On Thu, Jan 2, 2025 at 4:52 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
No. We obviously cannot guarantee correct output in the face of
arbitrarily incorrect input. What I'm doing is being practical about
how the real world works. People use NFS. This is not that different
from the fsync debacle a few years ago -- the fsync semantics on Linux
did (and AFAIK, still do) make it impossible to write correct
programs, and then on top of that our code had bugs in it, too. We
didn't just say "oh, well, I guess you shouldn't use Linux". We tried
to make our code as robust as it could be in the face of kernel code
that behaved in a manner that was fairly ridiculous relative to our
needs. This case doesn't seem that different to me.
I certainly think it's reasonable to debate whether any particular
mitigations that someone might propose adding to our code are
unreasonably difficult. But the complaint as presented is "the code
you used to have worked better than the code you have now," which
doesn't necessarily support the idea that the requested changes are
unreasonable. Of course, if FreeBSD is buggier than it needs to be,
then I hope that also gets fixed. But even if it doesn't, surely the
right thing to do would be to clearly document that we don't work
*with NFS on FreeBSD* rather than that we don't work with *any NFS*.
Unless of course we really (and unavoidably) don't work with any NFS,
and then we should document that, with reasons.
--
Robert Haas
EDB: http://www.enterprisedb.com
