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

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

On 01/02/2025 3:42 pm, Thomas Munro wrote:
> On Fri, Jan 3, 2025 at 10:16 AM Larry Rosenman <ler(at)lerctr(dot)org> wrote:
>> What about doing what Rick suggests?
>> do {
>> dir = opendir("X");
>> dp = readdir(dir);
>> if (dp != NULL)
>> unlink(dp->d_name);
>> close(dir);
>> } while (dp != NULL);
>> ?
>
> That only works for unlink loops where we expect no concurrent
> modifications. DROP DATABASE qualifies, but we use readdir() on
> directories that might be changing in various other places, including
> backups. They'd silently fail to do their job, and can't use that
> technique as they aren't unlinking as they go and so they would never
> make progress. Which leads to the lipstick/pig conclusion: we'd have
> other, worse, buggy behaviour still.
>
> It might be possible to make our own readdir snapshot thing that
> checks a shmem counter of all links/unlinks before and after and
> retries. But ugh...

Would it make sense for ONLY drop database to have the above loop?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler(at)lerctr(dot)org
US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-01-02 22:56:02 Re: Fwd: Re: A new look at old NFS readdir() problems?
Previous Message Sami Imseih 2025-01-02 22:33:33 Re: Vacuum statistics