Re: Fwd: Re: A new look at old NFS readdir() problems?
От | Larry Rosenman |
---|---|
Тема | Re: Fwd: Re: A new look at old NFS readdir() problems? |
Дата | |
Msg-id | 591325bbdbe5e39cca9eba2898f57ad4@lerctr.org обсуждение исходный текст |
Ответ на | Fwd: Re: A new look at old NFS readdir() problems? (Larry Rosenman <ler@lerctr.org>) |
Ответы |
Re: Fwd: Re: A new look at old NFS readdir() problems?
|
Список | pgsql-hackers |
On 01/02/2025 3:42 pm, Thomas Munro wrote: > On Fri, Jan 3, 2025 at 10:16 AM Larry Rosenman <ler@lerctr.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@lerctr.org US Mail: 13425 Ranch Road 620 N, Apt 718, Austin, TX 78717-1010
В списке pgsql-hackers по дате отправления: