- Jan 27, 2025
-
-
- Jan 24, 2025
-
-
Dmitry Rodionov authored
Ideally we should add ability to configure the value, becase for tests this timeout is unreasonably high.
-
Andrey Strochuk authored
-
- Jan 23, 2025
-
-
Erik Khamitov authored
-
- Jan 22, 2025
-
-
Georgy Moshkin authored
Previously in our integration tests we would explicitly provide instance names on startup. One of the reasons for that was, that we process all the logging output from the instances by adding the prefix with the instance name to them. After we stopped generating names explicitly this feature broke, and the logs started being prepended with just the listen port, which is not as useful. This commit partially resolves this issue by making it so that logging prefix is automatically updated after the instance is bootstrapped and we find out it's name. This is implemented just by checking the Instance.name member variable, which is updated when Instance.instance_info() method is called. It is implicitly called in Instance.wait_online() which happens in almost every test (often implicitly as well). But if you notice that your test output doesn't contain instance names at the start of the lines, you may want to call Instance.instance_info() explicitly at some point. Also note that there's an inherent problem with that approach -- any log output which is handled before the instance name is known will be prefixed with just the port number. Hopefully this is not a very big problem in most cases... A better solution would be to add the instance_name to all the logger output automatically from picodata. See #1303
-
Вартан Бабаян authored
-
- Jan 21, 2025
-
-
Alexander Tolstoy authored
-
EmirVildanov authored
Inside of string literals two subsequent single quotes are parsed as a single one. The only exception is plugin values which are considered to be json string and where single quotes are not escaped.
-
Denis Smirnov authored
-
- Jan 20, 2025
-
-
Georgy Moshkin authored
This reverts commit 6e91279f
-
Denis Smirnov authored
Cartridge CI often fails with timeout errors on the vshard bootstrap step. The reason is that cartridge uses default CALL_TIMEOUT_MIN in vshard, that is 0.5 sec by default. As our CI is often busy with concurrent jobs, current commit enlarges timeout 10 times up to 5 sec.
-
- Jan 17, 2025
-
-
Denis Smirnov authored
-
-
-
Denis Smirnov authored
The main problem is that this test didn't wait properly until the target instance is expelled. The correct logic could be found in the test_join_expel_instance for audit. So, current commit unifies the logic in both tests and adds some new methods to the Cluster class.
-
- Jan 16, 2025
-
-
Georgy Moshkin authored
-
Georgy Moshkin authored
Closes #996 This was the intended behavior all along, but I erroneously remove it thinking that it's a bad thing that we're going to be having references from _pico_plugin_migration to plugins which don't exist. If you drop the plugin leaving it's data, the only way to drop that data would be to re-create the same plugin and then drop it using `DROP PLUGIN WITH DATA` syntax. Also note that there's currently no way to drop the plugin's data without dropping the plugin itself (other then from lua via pico.migration_down but no analogue in SQL).
-
Georgy Moshkin authored
test_plugin_remove is split into 2: test_drop_plugin_basics and test_drop_plugin_with_or_without_data. The use of lua plugin api is replaced with SQL plugin api (except for down_migration, because there's no alternative in SQL API).
-
Georgy Moshkin authored
There was also a bug in storage::Plugins::get_all_versions. Close #1283
-
Prints all current members of the cluster and their status. The same result can be achieved by executing SQL query to system tables.
-
-
- Jan 15, 2025
-
-
-
We actually need only a single field: target_dir. It makes no sense to make network calls and get back a dump of json.
-
Georgy Moshkin authored
-
Georgy Moshkin authored
Plugin tests should generate the plugin metadata files automatically in the body of the test, so it's simpler to read and understand where the data comes from.
-
- Jan 14, 2025
-
-
Here is how DROP USER IF EXISTS query can result in such error: - [client 1]: check user exists - [client 1]: send CAS request 1 - [client 2]: check user exists - [client 2]: send CAS request 2 - [leader]: recv CAS request 1 -> access_check: ok -> check predicate: ok -> apply(async) - [leader]: recv CAS request 2 -> access_check: no such user /|\ | | applied To address such errors, access_check was made to not return errors when trying to drop non-existent users or roles. Now the above example is handled as follows: When a user is dropped during handling the request, it causes a schema change that leads to the rejection of the operation on the predicate check. Upon retry, the initiator will detect that the user has been dropped and handle it accordingly.
-
Виталий Шунков authored
-
- Jan 13, 2025
-
-
Вартан Бабаян authored
Replicaset name: {tier_name}_{replicaset_number_in_this_tier} Instance name: {tier_name}_{replicaset_number}_{instance_number_in_replicaset}
-
CONFIG_SITE is an environment variable which may point to a global autoconf initialization script, which is run at the start of every autoconf invocation and can modify its parameters. Most systems don't have that script, and don't set that variable. On OpenSUSE, the variable is set. The default script overwrites paths to local builds of libraries from `lib` to `lib64`, breaking our builds. This override makes no sense for our project, since all libraries are linked statically, and only ever built in 64-bit versions (the script allows side by side 32- and 64-bit builds). It is unlikely that this script is used in practice, since the possibility of breaking random builds is too high. It's also relevant only for building C code which relies on autoconf. Most new projects and projects in modern languages don't do that. For this reason I unset CONFIG_SITE in our default builds of Tarantool.
-
Антон Фетисов authored
-
- Jan 10, 2025
-
-
-
-
Diana Tikhonova authored
Added a `wait_index` parameter to `proc_replication_demote` to improve synchronization during demotion operations.
-
Diana Tikhonova authored
-
Diana Tikhonova authored
-
Enhanced `test_long_term_transaction_causing_rpc_timeouts` to validate that the `raft_term` remains unchanged during timeouts.
-
Updated `test_successful_wakeup_after_ddl` to validate that `raft_term` remains unchanged after a successful wakeup operation.
-
Key updates include: Adding the term field to relevant RPC requests (ConfigureReplicationRequest, ReplicationSyncRequest, and DemoteRequest). Utilizing node.status().check_term(req.term) in critical sections of the replication logic.
-
Erik Khamitov authored
-
Erik Khamitov authored
-