[DocDB] YBOperation.partition_key encoding should respect null value #12190

arybochkin · 2022-04-18T15:22:06Z

Jira Link: [DB-363](https://yugabyte.atlassian.net/browse/DB-363)

Description

Let's assume the following example

# create table test1(id int primary key, name text);
# create unique index idx1 on test1(name ASC) split at values(('p'));
# insert into test1 values(3, 'p');

and encoded partition bound looks like 5370000021 in hex

In accordance with documentation column ybuniqueidxkeysuffix may be of kNullLow, kNullHigh or base table ctid values. Hence the following possible YBOperation.partition_key should be concerned as correctly encoded values (in hex):

537000002421 > 5370000021
537000007C21 > 5370000021
537000005347C0C4488000010001022121000021> 5370000021

In all of these cases the write operation will be forwarded to a correct tablet as all possible values for the first byte are greater than the encoded value of kGroupEnd == 0x21.
But as of now, first and second options are encoded with 537000000021 < 5370000021. Mainly, this is happening because QLValuePB::VALUE_NOT_SET is treated as kLowest for a YBOperation.partition_key, but should not. There is a stack of calls that leads to the inconsistency:
GetRangeComponents()
GetRangePartitionKey()
InitWritePartitionKey()

The fact the YBOperation.partition_key has incorrect format is also confirmed by a manual decoding (via unit test), the following error appears:
Error when decoding range components of a document key: Expected a primitive value type, got kLowest.

Note. Refer to KeyEntryValue::NullValue() and PostgreSQL documentation for details on how null should be encoded. By default NULL LAST approach is used or ASC ordering and NULL FIRST for DESC ordering.

Step to reproduce the issue:

Create a cluster with enable_automatic_tablet_splitting=true:

./bin/yb-ctl create --master_flags="enable_automatic_tablet_splitting=true,tablet_split_low_phase_shard_count_per_node=16,tablet_split_low_phase_size_threshold_bytes=13421" --tserver_flags="yb_num_shards_per_tserver=1"

Create a table and a unique index

# create table test1(id int primary key, name text);
# create unique index idx1 on test1(name ASC) split at values(('p'));

Tablets info after statements have been executed:

yugabyte        idx1       000033e1000030008000000000004005        d75c1be78e94456d9803758d6650a897        range: [<start>, DocKey([], ["p"]))
yugabyte        idx1       000033e1000030008000000000004005        b5531d9aa54a45fb821fcf2baca3f268        range: [DocKey([], ["p"]), <end>)

Insert a row with a value that matches partition bounds

# insert into test1 values(3, 'p');

YBOperation is forwarded to the first tablet d75c1be78e94456d9803758d6650a897 as YBOperation.partition_key is less than the second partition lower bound: 537000000021 < 5370000021. But the operation should have been forwarded to the second tablet in accordance with range bounds. Tablets dump confirms the inserted row is persisted in the first tablet (with respect to DocDB format):

tablet-d75c1be78e94456d9803758d6650a897 in readable format:
SubDocKey(DocKey([], ["p", null]), [SystemColumnId(0); HT{ physical: 1649185585666746 }]) -> null; intent doc ht: HT{ physical: 1649185585665110 }
SubDocKey(DocKey([], ["p", null]), [ColumnId(12); HT{ physical: 1649185585666746 w: 1 }]) -> "G\xfc\xa0H\x80\x00\x00\x03!!"; intent doc ht: HT{ physical: 1649185585665110 w: 1 }

Data Block # 1 @ 0051
--------------------------------------
  HEX    5370000024214A80238001785106292545804A: 238001785106292BA9804A24
  ASCII  S p : # Ä  x Q  ) + © Ä J $ 
  ------
  HEX    5370000024214B8C238001785106292545803FAB: 238001785106292BA9803FAB5347FCA048800000032121
  ASCII  S p : # Ä  x Q  ) + © Ä ? ´ S G ¸ † H Ä 
  ------

tablet-b5531d9aa54a45fb821fcf2baca3f268
<empty>

The text was updated successfully, but these errors were encountered:

arybochkin · 2022-04-18T15:45:41Z

Another example.

Create a cluster

./bin/yb-ctl create --master_flags="enable_automatic_tablet_splitting=false"

2 Create a table and a unique index

# create table employees(id int primary key, name text, description text);
# create unique index idx1 on employees(description ASC);

Tablet and tablets info after (1) and (2) have been executed:

yugabyte        test1   000033e1000030008000000000004000        9cbdf6c37ea04fcda1f588e6942de292        hash_split: [0x0000, 0x7FFF)
yugabyte        test1   000033e1000030008000000000004000        5de68de4ae5d4a2897141761e40bc689        hash_split: [0x7FFF, 0xFFFF)
yugabyte        idx1    000033e1000030008000000000004001        4b9381341ce74522832665cf69e11a90        range: [<start>, <end>)

Download collect_insert_data.txt and rename to collect_insert_data.py
Modify the collect_insert_data.py in order it created a sql script with for insertion first 10 rows only, and execute the script
python collect_insert_data.py
Execute sql script

./bin/ysqlsh -f sql_data.sql

Insert a series of 4 rows with null values

# insert into employees values(11, 'new_name', null);
# insert into employees values(12, 'new_name', null);
# insert into employees values(13, 'new_name', null);
# insert into employees values(14, 'new_name', null);

Execute select count for different cases

# select count(*) from employees;
 count 
-------
    14
(1 row)

# select count(*) from employees where description is null;
 count 
-------
     4
(1 row)

Flush and dump the tablet

./yb-ts-cli flush_tablet 4b9381341ce74522832665cf69e11a90
./sst_dump --file=tablet-4b9381341ce74522832665cf69e11a90/ --command=scan --output_format=decoded_regulardb

Shortened dump:

Process tablet-4b9381341ce74522832665cf69e11a90/000010.sst
Sst file format: block-based
SubDocKey(DocKey([], ["Canal building…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["Canal building…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["Engineering has existed…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["Engineering has existed…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["In this context…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["In this context…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["John Smeaton was…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["John Smeaton was…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["Later, as the design…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["Later, as the design…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["Similarly, in addition…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["Similarly, in addition…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["The science of classical…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["The science of classical…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["The term engineering…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["The term engineering…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["The word engine itself…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["The word engine itself…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], ["With the rise of…", null]), [SystemColumnId(0)...])
SubDocKey(DocKey([], ["With the rise of…", null]), [ColumnId(12)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x1c99…)…, [SystemColumnId(0)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x1c99…)…, [ColumnId(12)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x37f1…)…, [SystemColumnId(0)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x37f1…)…, [ColumnId(12)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x41ca…)…, [SystemColumnId(0)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0x41ca…)…, [ColumnId(12)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0xcd71…)…, [SystemColumnId(0)...])
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0xcd71…)…, [ColumnId(12)...])

Last eight records in hexadecimal format:

7C53471C99...0000214A80...
7C53471C99...0000214B8C...
7C534737F1...0000214A80...
7C534737F1...0000214B8C...
7C534741CA...0000214A80...
7C534741CA...0000214B8C...
7C5347CD71...0000214A80...
7C5347CD71...0000214B8C...

Please mention how null is persisted on disk – it is 0x7C despite the fact the index is declared as (description ASC), NULL LAST approach is used for null values for regular columns, refer to KeyEntryValue::NullValue() and PostgreSQL documentation

Execute manual tablet splitting and wait until two new tablets appear

./yb-admin split_tablet \
-master_addresses localhost:7100 4b9381341ce74522832665cf69e11a90

Index tablets info after splitting has been executed:

yugabyte        idx1       000033e1000030008000000000004005        d67753006820420994182f684bb11ff6
range: [<start>, DocKey([], ["Similarly, in addition…, null]))
yugabyte        idx1       000033e1000030008000000000004005        299f23ab9a4f4e61bcdbe07722765d50
range: [DocKey([], ["Similarly, in addition…, null]), <end>)

Tablet partition boundary in hex: 5353696D696C61726C792C20…7300002421

Table idx1: table_partition_list: { version: 0 keys: ["", "SSimilarly...\x00\x00$!"] }
Note: DocKey([], ["Similarly, in addition…, null]) == "SSimilarly, in addition\x00\x00$!" == 5353696D696C61726C792C20696E206164646974696F6E...0000242116

Content of tablets is looking as expected with respect to split key (matches partitions bound, see above):

tablet-d67753006820420994182f684bb11ff6:
SubDocKey(DocKey([], ["Canal building…", null]), [SystemColumnId(0)...])
...
SubDocKey(DocKey([], ["Later, as the design…", null]), [ColumnId(12)...])

tablet-299f23ab9a4f4e61bcdbe07722765d50:
SubDocKey(DocKey([], ["Similarly, in addition…", null]), [SystemColumnId(0)...])
...
SubDocKey(DocKey([], [null, EncodedSubDocKey(DocKey(0xcd71…)…, [ColumnId(12)...])

Insert one more row with null value

# insert into employees values(15, 'new_name', null);

The rows count gives the following results:

# select count(*) from employees
 count 
-------
    15
(1 row)

# SET enable_indexscan = off;
# select count(*) from employees where description is null
 count 
-------
     5
(1 row)

# SET enable_indexscan = on;
# select count(*) from employees where description is null
 count 
-------
     4
(1 row)

But it is expected to have 5 for last case as well. This is happening due to YBOperation is forwarded to a wrong tablet due to YBOperation.partition_key contains incorrectly encoded null value == 0x00, but should be 0x7C for this case.

…ith range partitioning Summary: Issue #12190 gives a potential data loss, a temporary disabling for both dynamic and manual splitting for index tables with range partitioning is required at master server side. When #12190 and #12191 are done tablet splitting should be enabled for those tables. Additional tablet splitting disabling is added at tablet server side, other checks and cases will be covered in #12189. Additionally, an index versioning support is implemented by adding a new field `partition_key_version` into schema's `TableProperties` and `TablePropertiesPB` -- the default version should be updated in the context of #12190, after that tablet splitting becomes enabled automatically for index tables with range partitioning. Test Plan: Main: 1. unit test: ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "PgTabletSplitTest.ManualSplitIndexTablet" 2. manual test: 2.1) create a cluster ``` ./bin/yb-ctl create --master_flags="enable_automatic_tablet_splitting=true,\ tablet_split_low_phase_shard_count_per_node=16,\ tablet_split_low_phase_size_threshold_bytes=13421" \ --tserver_flags="yb_num_shards_per_tserver=1" ``` 2.2) run `./bin/ysqlsh` and execute ``` create table employees(id int primary key, name text, description text); create index idx1 on employees(description ASC); ``` 2.3) open tablet server web ui and make sure only one tablet exists for index table 2.4) download `collect_insert_data.txt` from #10926 and rename to `collect_insert_data.py` 2.5) execute `./collect_insert_data.py` to generate sql script 2.6) execute `./bin/ysqlsh -f sql_data.sql` 2.7) make sure only one tablet still exists for index table, while the table has several tablets 2.8) flush `idx1` index tablet: `./bin/yb-ts-cli flush_tablet <UUID>` 2.9) try manual split: `./bin/yb-admin split_tablet -master_addresses localhost:7100 <UUID>` the following error should appear: ``` Error running split_tablet: Not implemented (yb/master/tablet_split_manager.cc:176): Unable to start split of tablet <UUID>: Tablet splitting is not supported for the index table "idx1" with table_id "000033e5000030008000000000004005". Please, rebuild the index! ``` 3. Additional tests should not give unexpected results: ybd --cxx-test tablet_tablet-split-test ybd --cxx-test integration-tests_tablet-split-itest ybd --cxx-test integration-tests_tablet_server-itest ybd --cxx-test integration-tests_cql-tablet-split-test ybd --cxx-test integration-xcluster-tablet-split-itest ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestSchema ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestCreateProjection ybd --cxx-test master_catalog_manager-test --gtest_filter "TestCatalogManager.CheckIfCanDeleteSingleTablet" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "PgTabletSplitTest.SplitDuringLongRunningTransaction" ybd --cxx-test pgwrapper_pg_mini-test --gtest_filter "PgMiniTest.TabletSplitSecondaryIndexYSQL" Reviewers: timur, rthallam Reviewed By: timur, rthallam Subscribers: zyu, ybase, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D16738

… index tables with range partitioning Summary: Issue #12190 gives a potential data loss, a temporary disabling for both dynamic and manual splitting for index tables with range partitioning is required at master server side. When #12190 and #12191 are done tablet splitting should be enabled for those tables. Additional tablet splitting disabling is added at tablet server side, other checks and cases will be covered in #12189. Additionally, an index versioning support is implemented by adding a new field `partition_key_version` into schema's `TableProperties` and `TablePropertiesPB` -- the default version should be updated in the context of #12190, after that tablet splitting becomes enabled automatically for index tables with range partitioning. Original commit: 2ef55c8 / D16738 Test Plan: Main: 1. unit test: ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "PgTabletSplitTest.ManualSplitIndexTablet" 2. manual test: 2.1) create a cluster ``` ./bin/yb-ctl create --master_flags="enable_automatic_tablet_splitting=true,\ tablet_split_low_phase_shard_count_per_node=16,\ tablet_split_low_phase_size_threshold_bytes=13421" \ --tserver_flags="yb_num_shards_per_tserver=1" ``` 2.2) run `./bin/ysqlsh` and execute ``` create table employees(id int primary key, name text, description text); create index idx1 on employees(description ASC); ``` 2.3) open tablet server web ui and make sure only one tablet exists for index table 2.4) download `collect_insert_data.txt` from #10926 and rename to `collect_insert_data.py` 2.5) execute `./collect_insert_data.py` to generate sql script 2.6) execute `./bin/ysqlsh -f sql_data.sql` 2.7) make sure only one tablet still exists for index table, while the table has several tablets 2.8) flush `idx1` index tablet: `./bin/yb-ts-cli flush_tablet <UUID>` 2.9) try manual split: `./bin/yb-admin split_tablet -master_addresses localhost:7100 <UUID>` the following error should appear: ``` Error running split_tablet: Not implemented (yb/master/tablet_split_manager.cc:176): Unable to start split of tablet <UUID>: Tablet splitting is not supported for the index table "idx1" with table_id "000033e5000030008000000000004005". Please, rebuild the index! ``` 3. Additional tests should not give unexpected results: ybd --cxx-test tablet_tablet-split-test ybd --cxx-test integration-tests_tablet-split-itest ybd --cxx-test integration-tests_tablet_server-itest ybd --cxx-test integration-tests_cql-tablet-split-test ybd --cxx-test integration-xcluster-tablet-split-itest ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestSchema ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestCreateProjection ybd --cxx-test master_catalog_manager-test --gtest_filter "TestCatalogManager.CheckIfCanDeleteSingleTablet" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "PgTabletSplitTest.SplitDuringLongRunningTransaction" ybd --cxx-test pgwrapper_pg_mini-test --gtest_filter "PgMiniTest.TabletSplitSecondaryIndexYSQL" Reviewers: rthallam, timur Reviewed By: rthallam, timur Subscribers: bogdan, ybase Differential Revision: https://phabricator.dev.yugabyte.com/D17001

@tnayak

…pect null value Summary: #12190: YBOperation.partition_key encodes NULLs with no respect to column's sorting type. This leads to a situation when YBOperation with such partition_key is forwarded to a wrong tablet. In case of index tables such incorrect forwarding leads to a data loss for the dynamic tablet splitting: the YBOperation is skipped during applying of intents due to filtering out by tablet's key_bounds. The intent of the fix is to update YBOperation.partition_key generation algo to take column's sorting type into account and make the operation be forwarded correctly. #12191: Index tables contain a hidden system column `ybuniqueidxkeysuffix` or `ybidxbasectid` in a primary key that is not taken into account for partitions calculation for `split at` statement. This leads to a structure inconsistency between tablet partition bounds, tablet key bouds (splitting related, row's DocKey structure and YBOperation.partition_key, while the docdb layer expects all these entities structure to be the same. The fix extends tablet partition bound keys to set up `-Inf` for the hidden column explicitly -- same way it is done for the range columns whose values are not explicitly specified by `split at` statement, refer to `YBTransformPartitionSplitPoints()` Additionally, `GetRangeComponents()` fixed to remove a small regression added with D15429 (commit a2aa0d3): originally `docdb::ValueType::kHighest` had been added to the `upper_bounds` after `GetRangeComponents ()` returned the range components, but due to mentioned update in the method, `docdb::ValueType::kHighest` was begun to be added after each range component but the last one (!). This change also returns the original intention to add `docdb::ValueType::kHighest` only once at the end, confirmed with @tnayak. Additionally, partitioning_version is used for backward compatibility, to distinguish old and new tables to be able to read incorrectly persisted data in the past (but the splitting of such old tablets is kept disabled). The issue and the fix are mainly impact index tables and regular tables cannot have NULLs in a primary key. Test Plan: ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.IndexRowsPersistenceAfterManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.UniqueIndexRowsPersistenceAfterManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.ManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.SplitAt/*" ybd --cxx-test tools_yb-backup-test_ent --gtest_filter "YBBackupTest.TestYCQLPartitioningVersion" ybd --cxx-test tools_yb-backup-test_ent --gtest_filter "YBBackupTest.TestYSQLPartitioningVersion" ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestSchema ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestCreateProjection ybd --cxx-test pgwrapper_pg_mini-test --gtest_filter "PgMiniTest.TabletSplitSecondaryIndexYSQL" Reviewers: timur, rskannan, tnayak, yguan, oleg Reviewed By: tnayak, oleg Subscribers: zyu, ybase, rthallam, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D17276

arybochkin · 2022-07-21T19:12:19Z

keeping opened to not forget to backport after version mismatch issue (#13168) is fixed.

@tnayak

…ding should respect null value Summary: Original commit: 61985b6 / D17276 [#12190]: YBOperation.partition_key encodes NULLs with no respect to column's sorting type. This leads to a situation when YBOperation with such partition_key is forwarded to a wrong tablet. In case of index tables such incorrect forwarding leads to a data loss for the dynamic tablet splitting: the YBOperation is skipped during applying of intents due to filtering out by tablet's key_bounds. The intent of the fix is to update YBOperation.partition_key generation algo to take column's sorting type into account and make the operation be forwarded correctly. [#12191]: Index tables contain a hidden system column ybuniqueidxkeysuffix or ybidxbasectid in a primary key that is not taken into account for partitions calculation for split at statement. This leads to a structure inconsistency between tablet partition bounds, tablet key bouds (splitting related, row's DocKey structure and YBOperation.partition_key, while the docdb layer expects all these entities structure to be the same. The fix extends tablet partition bound keys to set up -Inf for the hidden column explicitly -- same way it is done for the range columns whose values are not explicitly specified by split at statement, refer to YBTransformPartitionSplitPoints() Additionally, GetRangeComponents() fixed to remove a small regression added with D15429 (commit a2aa0d3): originally docdb::ValueType::kHighest had been added to the upper_bounds after GetRangeComponents () returned the range components, but due to mentioned update in the method, docdb::ValueType::kHighest was begun to be added after each range component but the last one (!). This change also returns the original intention to add docdb::ValueType::kHighest only once at the end, confirmed with @tnayak. Additionally, partitioning_version is used for backward compatibility, to distinguish old and new tables to be able to read incorrectly persisted data in the past (but the splitting of such old tablets is kept disabled). The issue and the fix are mainly impact index tables and regular tables cannot have NULLs in a primary key. Test Plan: ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.IndexRowsPersistenceAfterManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.UniqueIndexRowsPersistenceAfterManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.ManualSplit/*" ybd --cxx-test pgwrapper_pg_tablet_split-test --gtest_filter "*PgPartitioningVersionTest.SplitAt/*" ybd --cxx-test tools_yb-backup-test_ent --gtest_filter "YBBackupTest.TestYCQLPartitioningVersion" ybd --cxx-test tools_yb-backup-test_ent --gtest_filter "YBBackupTest.TestYSQLPartitioningVersion" ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestSchema ybd --cxx-test common_schema-test --gtest_filter TestSchema.TestCreateProjection ybd --cxx-test pgwrapper_pg_mini-test --gtest_filter "PgMiniTest.TabletSplitSecondaryIndexYSQL" Reviewers: oleg, rthallam Reviewed By: oleg, rthallam Subscribers: tnayak, ybase, asrivastava, bogdan Differential Revision: https://phabricator.dev.yugabyte.com/D20627

arybochkin · 2022-11-01T13:58:57Z

Backported to 2.14, hence closing.

arybochkin added area/docdb YugabyteDB core features status/awaiting-triage Issue awaiting triage labels Apr 18, 2022

arybochkin self-assigned this Apr 18, 2022

arybochkin mentioned this issue Apr 18, 2022

[DocDB] Table partition boundaries structure mismatch for indexes #12191

Closed

rthallamko3 added priority/critical Critical issue and removed status/awaiting-triage Issue awaiting triage labels Apr 20, 2022

arybochkin assigned tanujnay112 May 16, 2022

yugabyte-ci added the kind/bug This issue is a bug label May 16, 2022

yugabyte-ci unassigned tanujnay112 Jun 8, 2022

arybochkin mentioned this issue Jun 10, 2022

[DocDB] splitting: Disable tablet splitting for tablets with incorrectly persisted data #12189

Open

rthallamko3 added the 2.14 Backport Required label Oct 10, 2022

arybochkin closed this as completed Nov 1, 2022

arybochkin mentioned this issue May 5, 2023

[DocDB] [Tablet Splitting] Automatic tablet splitting is not happening for the range indexes(which are restored from backup) #17169

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[DocDB] YBOperation.partition_key encoding should respect null value #12190

[DocDB] YBOperation.partition_key encoding should respect null value #12190

arybochkin commented Apr 18, 2022 •

edited by jira bot

Loading

arybochkin commented Apr 18, 2022

arybochkin commented Jul 21, 2022 •

edited by ttyusupov

Loading

arybochkin commented Nov 1, 2022

[DocDB] YBOperation.partition_key encoding should respect null value #12190

[DocDB] YBOperation.partition_key encoding should respect null value #12190

Comments

arybochkin commented Apr 18, 2022 • edited by jira bot Loading

Description

arybochkin commented Apr 18, 2022

arybochkin commented Jul 21, 2022 • edited by ttyusupov Loading

arybochkin commented Nov 1, 2022

arybochkin commented Apr 18, 2022 •

edited by jira bot

Loading

arybochkin commented Jul 21, 2022 •

edited by ttyusupov

Loading