Re: pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows.
От | Justin Pryzby |
---|---|
Тема | Re: pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows. |
Дата | |
Msg-id | 20221025212102.GS16921@telsasoft.com обсуждение исходный текст |
Ответ на | pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows. (Thomas Munro <tmunro@postgresql.org>) |
Ответы |
Re: pgsql: Fix unlink() for STATUS_DELETE_PENDING on Windows.
|
Список | pgsql-committers |
On Tue, Oct 25, 2022 at 03:29:42AM +0000, Thomas Munro wrote: > Fix unlink() for STATUS_DELETE_PENDING on Windows. > > Commit f357233c assumed that it was OK to return ENOENT directly if > lstat() failed that way. If we got STATUS_DELETE_PENDING while trying > to unlink a file that we had already unlinked successfully once before > but someone else still had open (on a kernel version that has "pending" > unlinks by default), then we would no longer reach the retry loop in > pgunlink(). That loop claims to be only for handling sharing violations > (a different phenomenon), but the errno is the same. > > Restore that behavior with an explicit check, to see if it fixes the > occasional 'directory not empty' failures seen in the pg_upgrade tests > on CI. Further improvements are possible with proposed upgrades to > modern Windows APIs that would replace this convoluted code. > > Reported-by: Justin Pryzby <pryzby@telsasoft.com> > Reviewed-by: Michael Paquier <michael@paquier.xyz> > Discussion: https://postgr.es/m/20220920013122.GA31833%40telsasoft.com > Discussion: https://postgr.es/m/CA%2BhUKG%2BajSQ_8eu2AogTncOnZ5me2D-Cn66iN_-wZnRjLN%2Bicg%40mail.gmail.com ... > Details > ------- > https://git.postgresql.org/pg/commitdiff/e109e43921d21d069c03f18d7c9d8f4e5cb6a0c3 If I'm not wrong, this didn't fix the issue you said it fixed. cfbot says this ran 1h ago, and its HEAD^3 is e109e43. https://cirrus-ci.com/task/5939314583404544
В списке pgsql-committers по дате отправления: