You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am working on testing SlateDB Go implementation for concurrency violations with the work-in-progress FizzBee tool. I see that flushImmWALs method that is called by FlushWAL is not thread safe.
func (db *DB) flushImmWALs() error {
for {
oldestWal := db.state.oldestImmWAL()
// ... multiple threads could access the head of the queue and write the WAL
db.state.popImmWAL() // But when they try to pop, one of them fails.
// ...
}
return nil
}
From my understanding, All the WAL flushing logic must be handled in a single thread (and memtable flush handled in its own separate thread). The public/exposed db.FlushWAL method does it in the callers' thread itself.
A current solution should be, make db.FlushWAL() as private (it is called by the actual flush thread), but have a separate Flush method that sends a message to the flush go routine that then should trigger the flush, similar to the db.Close()
The text was updated successfully, but these errors were encountered:
I am working on testing SlateDB Go implementation for concurrency violations with the work-in-progress FizzBee tool. I see that
flushImmWALs
method that is called byFlushWAL
is not thread safe.The cause of this issue is at,
From my understanding, All the WAL flushing logic must be handled in a single thread (and memtable flush handled in its own separate thread). The public/exposed
db.FlushWAL
method does it in the callers' thread itself.A current solution should be, make
db.FlushWAL()
as private (it is called by the actual flush thread), but have a separate Flush method that sends a message to the flush go routine that then should trigger the flush, similar to thedb.Close()
The text was updated successfully, but these errors were encountered: