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

From Bruce Momjian
Subject Re: Fwd: Re: A new look at old NFS readdir() problems?
Date
Msg-id Z3b8IxMKCM1pfJPU@momjian.us
Whole thread Raw
In response to Re: Fwd: Re: A new look at old NFS readdir() problems?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Fwd: Re: A new look at old NFS readdir() problems?
List pgsql-hackers
On Thu, Jan  2, 2025 at 03:48:53PM -0500, Tom Lane wrote:
> Larry Rosenman <ler@lerctr.org> writes:
> > @Tom Lane: This is what Rick Macklem (NFS dev on FreeBSD) has to say on 
> > my issue.
> 
> Thanks for reaching out to him.  So if I'm reading this correctly,
> there's little point in filing a FreeBSD bug because it'll be
> dismissed as unfixable.
> 
> This leaves us in rather a nasty position.  Sure, we could rewrite
> rmtree() as Thomas suggested upthread, but I'm still of the opinion
> that that's smearing lipstick on a pig.  rmtree() is the least of
> our worries: it doesn't need to expect that anybody else will be
> modifying the target directory, plus it can easily restart its scan
> without complicated bookkeeping.  I doubt we can make such an
> assumption for all our uses of readdir(), or that it's okay to
> miss or double-process files in every one of them.
> 
> I'm still of the opinion that the best thing to do is disclaim
> safety of storing a database on NFS.

It would be nice to have some details on the docs about why NFS can
cause problems so we have something to point to when people ask.

-- 
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EDB                                      https://enterprisedb.com

  Do not let urgent matters crowd out time for investment in the future.





pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fwd: Re: A new look at old NFS readdir() problems?
Next
From: Tom Lane
Date:
Subject: Re: apply_scanjoin_target_to_paths and partitionwise join