Commits
- Commit:
7a1a2249a4110c6057b16ef1f156d8bfcac469c7
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
test: add additional tests for a strptime()
The testsuite "Datetime string parsing by format (detailed)"
tests parsing of a string with various conversion specifications.
However, `tostring(dt)` is used as a test oracle, and all these
testcases do not test some conversion specifications at all
because the metamethod `__tostring` for the datetime object uses
`:format()` with the default format string.
Due to missed tests for conversion specifications, the behavior
described in #10470 was missed:
```
tarantool> dt = date.parse('Mon', {format = '%a'})
tarantool> dt
---
- 1970-01-01T00:00:00Z
...
tarantool> dt:format('%a')
---
- Thu
...
```
The patch adds tests for `strptime` with all possible conversion
specifications described in strftime(3) [1][2].
1. https://man.freebsd.org/cgi/man.cgi?strftime(3)
2. https://pubs.opengroup.org/onlinepubs/009695399/functions/strptime.html
Follows up #8588
Follows up #6731
Relates to #10470
NO_CHANGELOG=testing
NO_DOC=testing
- Commit:
507390413c0524e9103947ecabee592f148986c2
- From:
- Sergey Bronnikov <sergeyb@tarantool.org>
- Date:
test: check a number of parsed characters
The patch adds additional assertions for a number of characters
parsed by `datetime.parse()`.
Follows up #6731
NO_CHANGELOG=codehealth
NO_DOC=codehealth
- Commit:
49e459ea9b039177aa70f7c32ac13f88312ee1ac
- From:
- Magomed Kostoev <mkostoevr@yandex.ru>
- Via:
- Serge Petrenko <35663196+sergepetrenko@users.noreply.github.com>
- Date:
memtx: accelerate count in the tree
Prior to this patch the count request had been performed in the memtx
in a straightforward way: we created an iterator by a type and key and
simply called its `next` method until it's exhausted. That means the
operation had a linear complexity, which could lead to DoS situations.
Also the count operation with ALL iterator hadn't been recorded in the
MVCC previously and had an erroneous logic (see the #10140). This is
fixed too as a side effect.
This patch makes the memtx tree index use a version of BPS tree with
the cardinality information enabled and takes advantage of its offset
based API to implement the count operation using tree lookups.
Since the method does not read each counted tuple now, MVCC subsystem
would be unaware of it. In order to fix this, this patch introduces a
new entity in the memtx transaction manager to track such operations:
GAP_COUNT, and the corresponding `memtx_tx_track_count` function.
The entity (gap item) is a record that a concurrent transaction has
counted tuples matching some key and iterator type in an index.
If a transaction creates such an entity, any insertion or deletion
of a matching tuple in the index will be conflicted with it. This
works differently for inserts and deletes:
1. If a concurrent transaction inserts a new matching tuple, then
its read_gaps list is modified like the counted transaction had
read the exact key of the tuple and found nothing. This creates
a conflict.
2. If a concurrent transaction deletes a matching tuple, then the
transaction that counted the tuple is inserted into the tuple
reader list: it pretends to have read the tuple prior to the
deletion. This creates a conflict.
The existing stories of matching dirty tuples are handled differently.
Since its's not stored directly whether the story is a product of an
insertion or a replacement, any matching visible tuple is marked as
read by the counting transaction and any matching invisible one is
marked as gap read, so the conflicting scenarios remain the same for
old stories.
One thing to be noted is that using the cardinality config introduces
a performance regression against the current version of memtx, this is
to be mitigated in the scope of #10322.
Part of #8204
Closes #10140
NO_DOC=perf improvement
NO_CHANGELOG=TBD when fully implemented
- Commit:
79fe74c2ffc3e5721e2d5622c8f08f23014b22e4
- From:
- Magomed Kostoev <m.kostoev@tarantool.org>
- Via:
- Serge Petrenko <35663196+sergepetrenko@users.noreply.github.com>
- Date:
memtx: refactor the in-index tuple stories iteration out
The `memtx_tx_index_invisible_count_slow` iterates over stoies of
tuples existing in the index in order to count invisible ones. A
similar functionality will be required when count gaps will be
implemented, so let's refactor this part out of the function and
make it macro.
Needed for #8204
NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring
- Commit:
89424284376966e184041c846c52ff69dc554b14
- From:
- Magomed Kostoev <m.kostoev@tarantool.org>
- Via:
- Serge Petrenko <35663196+sergepetrenko@users.noreply.github.com>
- Date:
memtx: split the `memtx_tx_tuple_clarify_impl` function
Prior to this patch the `memtx_tx_tuple_clarify_impl` function been
used in order to clarify a tuple from index. Similar functionality
regarding to top tuple stories will be required when count gaps will
be implemented, so let's split the function into two:
`memtx_tx_tuple_clarify_impl` and `memtx_tx_story_clarify_impl`, and
make the first one call the latter.
Needed for #8204
NO_DOC=refactoring
NO_TEST=refactoring
NO_CHANGELOG=refactoring