Dear Alexander,
>
> Please look at the simple test program attached. It demonstrates the
> failure for me when running in two sessions as follows:
> unlink-open test 150 1000
> unlink-open test2 150 1000
Thanks for attaching a program. This helps us to understand the issue.
I wanted to confirm your env - this failure was occurred on windows server XXXX, right?
>
> That is, my idea was to try removing a file through renaming it as a fast
> path (thus avoiding that troublesome state DELETE PENDING), and if that
> fails, to perform removal as before. May be the whole function might be
> simplified, but I'm not sure about special cases yet.
I felt that your result showed pgrename() would be more rarely delayed than unlink().
That's why a file which has original name would not exist when subsequent open() was called.
About special cases, I wanted seniors to check.
> > * IIUC, the important points is the latter part, which waits until the status is
> > changed. Based on that, can we remove a double rmtree() from
> cleanup_output_dirs()?
> > They seems to be add for the similar motivation.
>
> I couldn't yet reproduce a failure, which motivated that doubling (IIUC, it
> was observed in [1]), with c28911750 reverted, so I need more time to
> research that issue to answer this question.
Yeah, as the first place, this failure seldom occurred....
Best Regards,
Hayato Kuroda
FUJITSU LIMITED