tarantool / tarantool / 18905189408

88%

master: 88%

Build Type

push

github

Committed by locker

Commit Message

vinyl: fix deferred delete reader not aborted on WAL error

With deferred DELETEs enabled, `space.delete()` writes the DELETE
statement to the primary index write set only while statements for
secondary indexes are generated either when the transaction is prepared
(if the deleted tuple is found in the memory layer or cache) or on
compaction.

Now imagine the following scenario:

1. There are tuples `{1,1}` and `{2,2}` in the memory layer of a space
   with enabled deferred DELETEs, the primary index over field 1, and
   a unique secondary index over field 2.
2. A transaction deletes `{2,2}` by the primary key and blocks on WAL.
   When the statement is executed, the DELETE statement is written only
   to the primary index write set because of enabled deferred DELETEs,
   but when the transaction is prepared (`vy_tx_prepare()`),
   the corresponding statement for the secondary index is generated
   because the deleted tuple is found in the in-memory layer, see
   `vy_tx_handle_deferred_delete()`.
3. In the meantime, another transaction replaces `{1,1}` with `{1,2}`
   and yields execution. It doesn't violate the unique constraint of
   the secondary index because `{2,2}` was deleted although not yet
   confirmed.
4. Imagine a transient WAL error happens and the first transaction is
   rolled back. The second transaction must be aborted too in this case
   because it implicitly read the DELETE statement prepared but not
   confirmed by the first transaction, but it is successfully committed,
   resulting in the unique constraint violation!

When a transaction is rolled back due to a WAL write error, we do
abort all transactions that read statements prepared by it, see
`vy_tx_rollback_after_prepare()`, but to do that, we iterate over
statements that were inserted into the transaction write set.
The problem is, we don't insert deferred DELETE statements generated
when a transaction is prepared in `vy_tx_handle_deferred_delete()` into
the write set because... (continued)

Run Details

68723 of 116251 branches covered (59.12%)

5 of 5 new or added lines in 2 files covered. (100.0%)

35 existing lines in 18 files now uncovered.

103428 of 118117 relevant lines covered (87.56%)

1619010.14 hits per line