I'm seeing strange behavior and I'm wondering if it's a race condition.
The strange behavior is MySQL getting EEXIST
when trying to create a temporary file. MySQL reuses temp file names by default, and because it chooses names in order from a pool of names, the name #sql_<pid>_0.<ext>
is always chosen first if it is isn't already in use (the last 0 indicates the position of the name in the pool).
I know that NFS simulates unlink because of the requirement to preserve blocks on an open file. When you unlink a file on an NFS volume, the client instead renames the file, and then when processes on the client close it, finally do an unlink.
But what if I unlink the file, and then a second thread tries to recreate a file with the same name within a millisecond or so after the unlink?
Is it possible that the rename is asynchronous, and may be delayed enough that the second thread gets an EEXIST error even though my thread believes it has finished its unlink() call successfully?
0 Answers