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
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 |