-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On non-Windows OS, hold file lock while renaming WAL directory #6269
Conversation
Seems like this made This change just restores the code that existed before 5991209 for non-Windows platforms. Any ideas? |
w.Close() | ||
if err := os.Rename(tmpdirpath, dirpath); err != nil { | ||
return nil, err | ||
if runtime.GOOS == "windows" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Split these separate code paths into the files wal_windows.go
and wal_unix.go
with windows
and !windows
build constraints? Each file would provide a platform specific implementation of func (w *WAL) renameWal(tmpdirpath string) (*WAL, error)
for Create
to call.
|
5a39edf
to
1f5347c
Compare
Updated with these changes, thanks. I named the files |
A suffix that's used by go is preferable...
So, |
@@ -0,0 +1,23 @@ | |||
// +build !windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add the contents of $REPO_ROOT/.header
here or it won't pass CI
also keep the build constraint a line separate from the package declaration because it confuses godoc
<HEADER>
// +build !windows
package wal
Please fix the last few comments and change the commit title to something like "wal: hold file lock while renaming WAL directory on non-windows" so it fits the commit title format for CI. Should be good to merge after that. Thanks! |
In the Go source, when there's a |
Either |
Windows requires this lock to be released before the directory is renamed. But on unix-like operating systems, releasing the lock and trying to reacquire it immediately can be flaky if a process is forked around the same time. The file descriptors are marked as close-on-exec by the Go runtime, but there is a window between the fork and exec where another process will be holding the lock.
1f5347c
to
af4f822
Compare
Updated the PR, thanks. |
lgtm |
// See the License for the specific language governing permissions and | ||
// limitations under the License. | ||
|
||
// +build !windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
do we still need this build tag? the file name is already _unix.go
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The *_unix.go
files in the Go standard library all seem to have build tags, but the *_windows.go
files do not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ok. thanks.
lgtm |
The test failure is unrelated to this pr. Merging. |
Windows requires this lock to be released before the directory is
renamed. But on unix-like operating systems, releasing the lock and
trying to reacquire it immediately can be flaky if a process is forked
around the same time. The file descriptors are marked as close-on-exec
by the Go runtime, but there is a window between the fork and exec where
another process will be holding the lock.