Re: Fwd: Re: A new look at old NFS readdir() problems?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: Pgsql hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <tmunro(at)freebsd(dot)org>
Subject: Re: Fwd: Re: A new look at old NFS readdir() problems?
Date: 2025-01-02 20:48:53
Message-ID: 302248.1735850933@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Larry Rosenman <ler(at)lerctr(dot)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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2025-01-02 20:50:43 Re: Fwd: Re: A new look at old NFS readdir() problems?
Previous Message Lukas Fittl 2025-01-02 20:46:04 [PATCH] Optionally record Plan IDs to track plan changes for a query