- 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
-
- Jan 09, 2025
-
-
Maksim Kaitmazian authored
Part of #998
-
- Dec 28, 2024
-
-
This patch migrates tarantool-sys from a patched 2.11.2 to a patched 2.11.5. Here's some stats: ``` $ git log --oneline 2.11.2..2.11.5 | wc -l 308 $ git log --oneline 2.11.2..2.11.2-picodata | wc -l 173 $ git log --oneline 2.11.5..2.11.5-picodata | wc -l 155 ``` The difference in the number of patches (155 vs 173) is due to: * Squashes and cleanups (e.g. the notorious `Part of #37`). * Already applied upstream patches. It's not a vanilla 2.11.5, though. The branch also includes a handful of upstream vinyl fixes which haven't been released yet: ``` $ git log --oneline 2.11.5..release/2.11 | rg -i vinyl abbfac3181 vinyl: disable tautological DELETE optimization for deferred DELETEs 980bcdd1d3 vinyl: move cache invalidation from vy_tx_write to vy_lsm_set bfab99a10f vinyl: do not invalidate cache on commit after prepare 03b982e977 vinyl: fix cache invalidation on rollback of DELETE statement 878f3c04ac vinyl: fix handling of duplicate multikey entries in transaction write set 6f63cd1e0c vinyl: skip invisible read sources edf02d65d1 vinyl: fix handling of overwritten statements in transaction write set ``` Branch: https://git.picodata.io/core/tarantool/-/commits/2.11.5-picodata
-
Dmitry Rodionov authored
The patch adds support of ldap auth method to pgproto. For ldap we request user password in clear text using corresponding protocol message. Afterwards password is passed to tarantool `authenticate` method which handles ldap based auth. Important: since password is transferred as clear text it is advised to setup ssl.
-
Dmitry Rodionov authored
-
Dmitry Rodionov authored
glauth was installed in CI but we unconditionally skipped the test. Run the test depending on the glauth availability.
-
-
Вартан Бабаян authored
-
Dmitry Rodionov authored
-
Dmitry Rodionov authored
-
Dmitry Rodionov authored
-
Dmitry Rodionov authored
-
Вартан Бабаян authored
-
- Dec 27, 2024
-
-
Previously, using a default port of another protocol would result in an error like the following ``` error: Invalid value "localhost:8080" for '--pg-listen <[HOST][:PORT]>': PGPROTO cannot listen on port 8080 because it is default port for HTTP ``` This commit allows default ports to be used by other protocols, as long as the port is not already occupied. Close #1254
-
-
Georgy Moshkin authored
The bug was introduced when I changed the behaviour of conf_change in regard to instances with target_state Expelled. As a result we would sometimes arbitrarily demote healthy voters in presence of degenerate ones. For example we could have this situation: instance i1: raft_id=1, target_state=Online, raft_configuration=voter instance i2: raft_id=2, target_state=Expelled, raft_configuration=voter (!) instance i3: raft_id=3, target_state=Offline, raft_configuration=voter (!) instance i4: raft_id=4, target_state=Online, raft_configuration=learner (!) instance i5: raft_id=5, target_state=Online, raft_configuration=learner (!)
-
Georgy Moshkin authored
-
Georgy Moshkin authored
-
The check arrived late when elections were already completed. Circumstances are a bit weird. For some reason the check hang for two seconds. Only after that it received conn refused, and during these two seconds elections happened and leader was chosen so check can never succeed after that.
-
Виталий Шунков authored
-
Follow-up for !1425
-
-
Кирилл Безуглый authored
BREAKING CHANGE: as soon as PostgreSQL protocol is enabled by default, we must be careful with `--pg-listen` cli flag when creating more than a single instance, because we will suddenly get a port confict error (busy port)
-
- Dec 26, 2024
-
-
Виталий Шунков authored
-
- Dec 25, 2024
-
-
Dmitry Rodionov authored
Logs help to debug flaky tests. Because sometimes just by instance logs it is not that easy to guess what the test was doing at that time. Especially when there is a repetitive pattern in the test. For now instance logs and test output are printed in separate sections. It still allows to match events by time easier compared to looking only at instance log (it is way bigger compared to test log). Additionally this patch sets up a `framework` package intended to host reusable test code without polluting conftest.py
-
-
Dmitry Rodionov authored
I found this by compiling tarantool with CMAKE_BUILD_TYPE=Debug
-
Georgy Moshkin authored
We used to automatically truncate the index in compact_log if the caller requested to compact too many entries. This made it so that the requirement of not compacting any un-applied entries was implicit in our code base, which is not good as it allows for some bugs to creep in (like the one we fix a couple commits ago). Now this is changed and instead of silently adjusting the index of last compacted entry, we just assert that it's no greater than the applied index. As a consequence there's a minor improvement in do_raft_log_auto_compaction function.
-
Georgy Moshkin authored
-
Georgy Moshkin authored
There was a hard-to-reproduce bug in our snapshot application code. We always compact the raft log before applying the snapshot, because the snapshot replaces the entries and some of the logic in raft-rs seems to rely on this. The problem was, that our compact_log function would not remove any unapplied entries, which makes sense for compaction triggered automatically by raft log size, but doesn't make sense for raft snapshot, as the snapshot contains the state corresponding to the newer entries. The fix is simple: don't guard from unapplied entry compaction in case the compaction is for raft snapshot. We don't add any regression tests for this, because the implementation would be too difficult and would need us to pollute the code with error injection logic, which is not a worthy trade off in this case. But also the logic will still be tested, because this bug was responsible for a large amount of flaky tests, so we should see a significant reduction in flakiness from now on in tests concerning raft snapshots.
-
Georgy Moshkin authored
-
Erik Khamitov authored
-