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
