[YSQL] Secondary index + main table queries cannot withstand a rolling upgrade from 2.14 to anything 2.16+ #17380
Assignees
Labels
Comments
tanujnay112
added
area/ysql
yugabyte-ci
added
kind/bug
tanujnay112
added a commit
that referenced
this issue
May 23, 2023
…cans for upgrade compatibility Summary: `ybctid_column_value` is not set in index scans past 2.14, yet tserver code in 2.14 expect this to be filled in ybctid batch fetches. That causes upgrade issues that this change ameliorates. Test Plan: Jenkins Make a 2.14 cluster with two nodes and load the following table: ``` create table hhh (h int primary key, r int); create index hhh (h asc); insert into hhh values (1), (2), (3), (4), (5), (6); ``` Upgrade the second node to 2.16 and launch an index scan from that node to the old node: ``` SELECT * FROM hhh WHERE h <= 5; ``` The query runs to completion and returns results. Reviewers: mihnea, sergei, amartsinchyk Reviewed By: amartsinchyk Subscribers: yql Differential Revision: https://phorge.dev.yugabyte.com/D25538
tanujnay112
added a commit
that referenced
this issue
May 23, 2023
…sent in index scans for upgrade compatibility Summary: `ybctid_column_value` is not set in index scans past 2.14, yet tserver code in 2.14 expect this to be filled in ybctid batch fetches. That causes upgrade issues that this change ameliorates. Original commit: 91baa2c / D25538 Test Plan: Jenkins Make a 2.14 cluster with two nodes and load the following table: ``` create table hhh (h int primary key, r int); create index hhh (h asc); insert into hhh values (1), (2), (3), (4), (5), (6); ``` Upgrade the second node to 2.16 and launch an index scan from that node to the old node: ``` SELECT * FROM hhh WHERE h <= 5; ``` The query runs to completion and returns results. Reviewers: mihnea, sergei, amartsinchyk Reviewed By: amartsinchyk Subscribers: yql Differential Revision: https://phorge.dev.yugabyte.com/D25618
tanujnay112
added a commit
that referenced
this issue
May 23, 2023
…sent in index scans for upgrade compatibility Summary: `ybctid_column_value` is not set in index scans past 2.14, yet tserver code in 2.14 expect this to be filled in ybctid batch fetches. That causes upgrade issues that this change ameliorates. Original commit: 91baa2c / D25538 Test Plan: Jenkins Make a 2.14 cluster with two nodes and load the following table: ``` create table hhh (h int primary key, r int); create index hhh (h asc); insert into hhh values (1), (2), (3), (4), (5), (6); ``` Upgrade the second node to 2.16 and launch an index scan from that node to the old node: ``` SELECT * FROM hhh WHERE h <= 5; ``` The query runs to completion and returns results. Reviewers: mihnea, sergei, amartsinchyk Reviewed By: amartsinchyk Subscribers: yql Differential Revision: https://phorge.dev.yugabyte.com/D25617
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-6567
Description
If we make a configuration of the form:
Node 1 -> 2.14.6.0
Node 2 -> 2.16.2.0+
And execute the following queries from node 2
We get the following error
The cause of this is that when the upgraded node does a ybctid batch-fueled request to the old node, it does not populate the
ybctid_column_valuefield as of this commit. This causes us to run into this line on the old node.Warning: Please confirm that this issue does not contain any sensitive information
The text was updated successfully, but these errors were encountered: