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