Maksim Kaitmazian authored 7 months ago and Georgy Moshkin committed 7 months ago

A global lock for schema changes that solves the following issue:
An expensive index creation can cause RPC timeouts, resulting in re-sending of the
same RPC even though the operation is still in progress on the master. The second RPC
attempts to create the same index, but it realizes that the index already exists
even if the operation has not been completed yet. To handle this scenario, a global
lock was added in `proc_apply_schema_change` to prevent concurrent schema changes.

Closes #875

CAS predicates should always contain the current raft term, because this
is what's explicitly checked in proc_cas.

Note that this will sometimes result in a EntryTermMismatch error
because the latest applied entry may have a different term in case the
election has started but not finished yet.

We could add this check to all the client cas precondition checks, but
it's not a big deal, because we handle the situation correctly anyways.

Rolled back as in raft log roll back, which can happen when a leader
changes to one who doesn't have the entry we persisted.
Not to be confused with DdlAbort.

Nobody cares about the lsn

I'm not sure but I think it was added before we switched to counting
vshard config versions. Basically it was fixing the same A-B-A problem
but only in a single case.

Just goes to show how you shouldn't apply hacky fixes to problems you
don't fully understand.

BTW nobody is ever reading this message, the commit only removes the
code so nobody will ever bump into it going over git blame...

Not used yet

It's called proc_update_instance, not proc_replace_instance, duh!

Previously macros won't work when using solely picoplugin as SDK.
It is fixed in linked tarantool-module MR, this MR introduces tests for that.

Linked [MR](https://git.picodata.io/picodata/picodata/tarantool-module/-/merge_requests/542) in tarantool-module.