vshard.storage.bucket_stat() fails when called in trigger on vinyl space.

[aensidhe]

Setup

• I have vshard, properly bootstrapped.
• I have sharded space with vinyl engine.
• I have on_replace trigger on that space.
• I call vshard.storage.bucket_stat() to understand whether it is data change caused by the application or it is vshard rebalancing

Expected

I get the info about bucket

Actual

vshard.storage.bucket_stat() crashes with error: A multi-statement transaction can not use multiple storage engines

Important note: if my space would have memtx engine, everything works perfectly.

How to reproduce

1. Bootstrap vshard any way you want.
2. Connect to master of any replicaset.
3. Setup test space:

box.schema.create_space('test', { engine = 'vinyl' })
box.space.test:format{ { 'name': 'id', 'type': 'unsigned' }, { 'name': 'bucket_id', 'type': 'unsigned' } }
box.space.test:create_index('primary', { parts = { 'id' } })
box.space.test:create_index('bucket_id', { parts = { 'bucket_id' }, unique = false })
function f(old, new) print(vshard.storage.bucket_stat((old or new).bucket_id)) end
box.space.test:on_replace(f)

4. Run the test: box.space.test:insert{1, 1}
5. See the error: error: A multi-statement transaction can not use multiple storage engines

[R-omk]

What is more important is that it cannot make any ref(rf/ro) inside a vinyl transaction,

because in some cases the bucket state is read from a tuple:

vshard/vshard/storage/init.lua

Lines 1305 to 1306 in 2211be2

	elseif ref.rw == 0 then
	local _, err = bucket_check_state(bucket_id, 'write')

vshard/vshard/storage/init.lua

Lines 1197 to 1200 in 2211be2

	local function bucket_check_state(bucket_id, mode)
	assert(type(bucket_id) == 'number')
	assert(mode == 'read' or mode == 'write')
	local bucket = box.space._bucket:get({bucket_id})

---

.. in addition, reading from space is a much more expensive operation than reading from lua tables for these simple case

---

Also need to pay attention that the result of reading from space inside a transaction depends on the operating mode of the transaction (read-committed read-confirmed) , which can give rise to even more dangerous bugs.