9b99e3dfe0
The Append / truncate operations were racy. When a datafile reaches 2Gb, a new file is needed. For this operation, we require a writelock, which is not needed in the 99.99% of all cases where the data does fit in the current head-file. This transition from readlock to writelock was incorrect, and as the readlock was released, a truncate operation could slip in between, and truncate the data. This would have been fine, however, the Append operation continued writing as if no truncation had occurred, e.g writing item 5 where item 0 should reside. This PR changes the behaviour, so that if when we run into the situation that a new file is needed, it aborts, and retries, this time with a writelock. The outcome of the situation described above, running on this PR, would instead be that the Append operation exits with a failure. |
||
---|---|---|
.. | ||
accessors_chain_test.go | ||
accessors_chain.go | ||
accessors_indexes_test.go | ||
accessors_indexes.go | ||
accessors_metadata.go | ||
accessors_snapshot.go | ||
accessors_state.go | ||
chain_iterator_test.go | ||
chain_iterator.go | ||
database.go | ||
freezer_table_test.go | ||
freezer_table.go | ||
freezer.go | ||
schema.go | ||
table_test.go | ||
table.go |