Date: 2026-05-29
Time: 08:26
WriteAheadLog.openlatestopenlatest resumes writing to the most recent WAL file if it still has room, or triggers creation of a new one. It's the startup/recovery path that ensures self.fd and self.current_file point to a valid, writable WAL file after the object is constructed or after truncate() rewrites the log.
Without this method, the WAL would either always create a fresh file on startup (wasting space and fragmenting the log) or require the caller to decide which file to append to.
Preconditions:
self.dir exists (guaranteed by os.makedirs in init_).self.maxfile_size is a positive integer.self._fd may be None (true at init and after truncate closes it).Postconditions:
self._fd is an open file descriptor in binary-append mode.self.currentfile is the path to that file..wal file (if under the size cap) or a freshly created one.Invariant: After this method returns, the WAL is ready to accept write() calls on self._fd.
None — this is a private method operating entirely on instance state.
None. All output is through side effects on self.fd and self.current_file.
1. List existing WAL files — calls walfiles(), which returns lexicographically sorted .wal paths. Because filenames are zero-padded integers (000001.wal), lexicographic order equals chronological order.
2. Check if the latest file has room — if any files exist, it takes the last one and checks its on-disk size via os.path.getsize. If strictly less than maxfile_size, it opens that file in binary-append mode ("ab") and returns immediately.
3. Otherwise, rotate — if no files exist or the latest file is at/above the size cap, it delegates to _rotate(), which creates a new numbered WAL file and opens it.
The key decision is the < comparison: a file exactly at maxfilesize triggers rotation. This means the last write that pushed the file to or past the limit will land in the old file (written by maybe_rotate on the *next* call), and the next startup will correctly rotate.
self.fd) — the caller is responsible for eventually closing it (via close() or another rotate()).self.currentfile to the path of the active WAL file.rotate() is called, it may flush/fsync/close a previous self.fd (though at init time, fd is None so rotate skips that branch).No explicit error handling. The method can raise:
OSError/PermissionError from os.path.getsize() if the file was deleted between walfiles() and the size check (TOCTOU race).OSError from open(..., "ab") if the file is inaccessible._rotate() propagates unchanged.None of these are caught — a failure here is fatal to WAL construction, which is the correct behavior (you don't want a half-initialized WAL silently accepting writes).
Called in exactly two places:
1. _init_ — ensures the WAL is immediately writable after construction.
2. truncate — after rewriting/removing WAL files, re-opens the active file so subsequent appends work.
Both callers expect that after openlatest(), they can call self.fd.write() without further setup. This method is never called under self.lock directly — in _init_ there's no contention yet; in truncate, the lock is already held by the caller.
walfiles() — provides the sorted list of WAL file paths._rotate() — handles new-file creation, including flushing/closing the old file and numbering the new one.os.path.getsize() — used to check on-disk size rather than an in-memory counter, which means it reflects the true file size even after a crash/restart.000001.wal), so lexicographic sort equals numeric sort. If someone manually creates foo.wal in the directory, walfiles() will include it and _rotate() will crash on int(...).self.dir between the wal_files() call and the open().maxfilesize is positive. A zero or negative value would cause every call to fall through to rotate(), creating a new file each time.