[YSQL] [Index Backfill] Committing a pg_index row is not immediately visible to yb-master #5030
Assignees
Labels
Comments
frozenspider
changed the title
frozenspider
changed the title
|
For context, the pg_index read during the backfill permissions check is done in this function: https://github.com/yugabyte/yugabyte-db/blob/master/src/yb/master/backfill_index.cc#L154. |
frozenspider
added a commit
that referenced
this issue
Jul 10, 2020
Summary: `org.yb.pgsql.TestIndexBackfill` test has been failing for the following reasons: * Error message it was expecting to catch was changed in 8246ca4#diff-35b7aae825e891e35b810e7bc838ffe1L159 * For "schema version mismatch" transparent restart, when aborting transaction, we weren't cleaning up `debug_query_string` which remained pointing to the query allocated in the destroyed memory context - briefly, but it was subsequently used when logging, and was caught by ASAN It might still sometimes fail in ASAN though: * Because of #5030 * Weird case when test succeeds but our test framework reports it as a failure, possibly because of stray `postgres` processes left over after the test (Resolves #5044) Test Plan: ybd --java-test org.yb.pgsql.TestIndexBackfill (and ASAN as well) Reviewers: jason, mihnea Reviewed By: mihnea Subscribers: yql Differential Revision: https://phabricator.dev.yugabyte.com/D8878
frozenspider
added a commit
that referenced
this issue
Jul 10, 2020
Summary: `org.yb.pgsql.TestIndexBackfill` test has been failing for the following reasons: * Error message it was expecting to catch was changed in 8246ca4#diff-35b7aae825e891e35b810e7bc838ffe1L159 * For "schema version mismatch" transparent restart, when aborting transaction, we weren't cleaning up `debug_query_string` which remained pointing to the query allocated in the destroyed memory context - briefly, but it was subsequently used when logging, and was caught by ASAN It might still sometimes fail in ASAN though: * Because of #5030 * Weird case when test succeeds but our test framework reports it as a failure, possibly because of stray `postgres` processes left over after the test (Resolves #5044) Test Plan: ybd --java-test org.yb.pgsql.TestIndexBackfill (and ASAN as well) Reviewers: jason, mihnea Reviewed By: mihnea Subscribers: yql Differential Revision: https://phabricator.dev.yugabyte.com/D8878 (cherry picked from commit 91733d4)
|
According to |
|
I confirm that this happens even with rf 1. |
|
I think I've narrowed down to an explanation for what's going on. It looks like we commit the apply patch on commit 0542f16: diff --git i/src/yb/master/backfill_index.cc w/src/yb/master/backfill_index.cc
index d63999fe4..89d30db59 100644
--- i/src/yb/master/backfill_index.cc
+++ w/src/yb/master/backfill_index.cc
@@ -155,6 +155,7 @@ Result<bool> GetPgIndexStatus(
CatalogManager* catalog_manager,
const TableId& idx_id,
const std::string& status_col_name) {
+ LOG(WARNING) << __func__ << " ENTR";
const auto pg_index_id =
GetPgsqlTableId(VERIFY_RESULT(GetPgsqlDatabaseOid(idx_id)), kPgIndexTableOid);
@@ -199,10 +200,12 @@ Result<bool> GetPgIndexStatus(
QLTableRow row;
if (VERIFY_RESULT(iter->HasNext())) {
RETURN_NOT_OK(iter->NextRow(&row));
+ LOG(WARNING) << __func__ << " EXIT";
return row.GetColumn(status_col_id)->bool_value();
}
// For practical purposes, an absent index is the same as having false status column value.
+ LOG(WARNING) << __func__ << " EXIT";
return false;
}
@@ -217,6 +220,12 @@ Result<bool> ShouldProceedWithPgsqlIndexPermissionUpdate(
switch (new_perm) {
case INDEX_PERM_WRITE_AND_DELETE: {
auto live = VERIFY_RESULT(GetPgIndexStatus(catalog_manager, idx_id, "indislive"));
+ if (!live && catalog_manager->doaretry) {
+ LOG(WARNING) << "TRY AGAIN";
+ SleepFor(MonoDelta::FromMilliseconds(5000));
+ LOG(WARNING) << "DONE SLEEP";
+ live = VERIFY_RESULT(GetPgIndexStatus(catalog_manager, idx_id, "indislive"));
+ }
if (!live) {
VLOG(1) << "Index " << idx_id << " is not yet live, skipping permission update";
}
@@ -224,6 +233,12 @@ Result<bool> ShouldProceedWithPgsqlIndexPermissionUpdate(
}
case INDEX_PERM_DO_BACKFILL: {
auto ready = VERIFY_RESULT(GetPgIndexStatus(catalog_manager, idx_id, "indisready"));
+ if (!ready && catalog_manager->doaretry) {
+ LOG(WARNING) << "TRY AGAIN R";
+ SleepFor(MonoDelta::FromMilliseconds(5000));
+ LOG(WARNING) << "DONE SLEEP R";
+ ready = VERIFY_RESULT(GetPgIndexStatus(catalog_manager, idx_id, "indisready"));
+ }
if (!ready) {
VLOG(1) << "Index " << idx_id << " is not yet ready, skipping permission update";
}
@@ -911,7 +926,7 @@ BackfillTablet::BackfillTablet(
} else if (done()) {
VLOG(1) << tablet_->ToString() << " backfill already done";
} else {
- VLOG(1) << tablet_->ToString() << " begining backfill from "
+ VLOG(1) << tablet_->ToString() << " beginning backfill from "
<< "<start-of-the-tablet>";
}
}
diff --git i/src/yb/master/catalog_manager.cc w/src/yb/master/catalog_manager.cc
index b3b1dd0f6..3602b53e2 100644
--- i/src/yb/master/catalog_manager.cc
+++ w/src/yb/master/catalog_manager.cc
@@ -6057,10 +6057,12 @@ Result<uint64_t> CatalogManager::IncrementYsqlCatalogVersion() {
auto l = CHECK_NOTNULL(ysql_catalog_config_.get())->LockForWrite();
uint64_t new_version = l->data().pb.ysql_catalog_config().version() + 1;
l->mutable_data()->pb.mutable_ysql_catalog_config()->set_version(new_version);
+ LOG(WARNING) << "Incremented to " << new_version;
// Write to sys_catalog and in memory.
RETURN_NOT_OK(sys_catalog_->UpdateItem(ysql_catalog_config_.get(), leader_ready_term()));
l->Commit();
+ LOG(WARNING) << "COMMITTT";
return new_version;
}
@@ -6378,6 +6380,7 @@ Status CatalogManager::StartRemoteBootstrap(const StartRemoteBootstrapRequestPB&
void CatalogManager::SendAlterTableRequest(const scoped_refptr<TableInfo>& table,
const AlterTableRequestPB* req) {
+ if (req == nullptr) { doaretry = false; } else { doaretry = true; }
vector<scoped_refptr<TabletInfo>> tablets;
table->GetAllTablets(&tablets);
diff --git i/src/yb/master/catalog_manager.h w/src/yb/master/catalog_manager.h
index c4424fa6d..e14b46f01 100644
--- i/src/yb/master/catalog_manager.h
+++ w/src/yb/master/catalog_manager.h
@@ -164,6 +164,7 @@ class CatalogManager : public tserver::TabletPeerLookupIf {
};
public:
+ volatile bool doaretry;
// Some code refers to ScopedLeaderSharedLock as CatalogManager::ScopedLeaderSharedLock.
using ScopedLeaderSharedLock = ::yb::master::ScopedLeaderSharedLock;
diff --git i/src/yb/master/master_tablet_service.cc w/src/yb/master/master_tablet_service.cc
index dbef676bf..1229907e1 100644
--- i/src/yb/master/master_tablet_service.cc
+++ w/src/yb/master/master_tablet_service.cc
@@ -71,6 +71,7 @@ void MasterTabletServiceImpl::Write(const tserver::WriteRequestPB* req,
}
tserver::TabletServiceImpl::Write(req, resp, std::move(context));
+ LOG(WARNING) << "write done";
}
void MasterTabletServiceImpl::IsTabletServerReady(run: ./bin/yb-ctl create --master_flags "vmodule='backfill_index=3,tablet_service=2',TEST_docdb_log_write_batches=true,ysql_disable_index_backfill=false" --tserver_flags "vmodule='tablet_service=2',TEST_docdb_log_write_batches=true,ysql_disable_index_backfill=false"
./bin/ysqlshcreate table t1 (a int, b int, primary key (a asc)); insert into t1 values (1, 1), (2, 2), (3, 3); insert into t1 values (4, null), (5, null); create index on t1 (b asc); drop table t1; -- repeat until it gets stuck for 5 seconds (without patch, it would have timed out after 60 seconds)postgres log: tserver log: master log:
I later did more debugging to see that the problem seems to occur when
For |
|
It appears there may be more than one thing going on here. I have collected logs from several failures, and I grouped them up to two main types:
The first causes the newly written row to not get found. In the case of The second simply reads the wrong row. |
|
@tedyu pointed out an inaccuracy with my second issue in the previous comment. I confused column ids 19, 21, 22 to be indislive, indisready, indisvalid, respectively. |
jasonyb
pushed a commit
that referenced
this issue
Apr 13, 2023
Summary:
Online schema changes don't properly wait for all clients (postgres
backends) to be at an up-to-date schema (system catalog, catalog
version) before moving on to the next schema. Right now, there is only
one implementation of online schema change: CREATE INDEX. It does a
default 1s wait between index state flag changes. This can be
problematic if the schema was not fully propagated within 1s.
Fix to actually wait for all clients to be at an up-to-date schema. Do
so by waiting on all clients (on the same database) to have a requested
catalog version. The implementation details of this waiting are in a
code comment of ysql_backends_manager.h.
In order to get back the old behavior, set tserver flags
--ysql_yb_index_state_flags_update_delay=1000
--ysql_yb_disable_wait_for_backends_catalog_version=true.
Client-master RPC timeout is controllable by tserver flag
--wait_for_ysql_backends_catalog_version_client_master_rpc_timeout_ms
and common flag (meaning master and tserver flag expected to be set to
the same value)
--wait_for_ysql_backends_catalog_version_client_master_rpc_margin_ms.
The first flag defaults to 20s and determines the max time spent waiting
on master. The second flag defaults to 5s and accounts for any
additional time it takes for RPC overhead. The two flags are combined
to make the official RPC deadline.
The master-tserver RPC timeout is controllable by the master flag
--master_ts_rpc_timeout_ms, which is also used for other master-tserver
RPCs.
A WaitForYsqlBackendsCatalogVersion request typically creates a
BackendsCatalogVersionJob, viewable in master UI /tasks page. This job
launches the BackendsCatalogVersionTS master-tserver RPC tasks, also
viewable in master UI /tasks page. The job details tell how many
backends are still lagging behind, so this page can be consulted in case
of a long-running CREATE INDEX (that is stuck before backfill). In the
future, capabilities could be added to expose which backends are behind,
but for now, this information can be manually collected by running the
same SELECT query as in tablet_service.cc:
SELECT count(*) FROM pg_stat_activity WHERE catalog_version < $0 AND datid = $1
The master flag --ysql_backends_catalog_version_job_expiration_sec
determines how long jobs can be untouched by clients before being
candidates for expiration.
Close: #7376
Test Plan:
./yb_build.sh fastdebug --gcc11 \
--cxx-test pgwrapper_pg_backends-test
./yb_build.sh release \
--cxx-test pgwrapper_pg_backends-test \
--gtest_filter PgBackendsTest.Stress
./yb_build.sh fastdebug --gcc11 \
--cxx-test pgwrapper_pg_index_backfill-test \
--gtest_filter PgIndexBackfillTest.InsertsWhileCreatingIndex
./yb_build.sh fastdebug --gcc11 -n 100 --tp 1 --java-test \
'org.yb.pgsql.TestIndexBackfill#insertsWhileCreatingIndex'
./yb_build.sh asan -n 10 --tp 1 --java-test \
'org.yb.pgsql.TestIndexBackfill#insertsWhileCreatingIndex'
There could be some flaky failures with error
Requested catalog version is too high:
due to issue #5030 still not resolved. This is mainly hit by the
PgBackendsTest.CachedJob test.
Reviewers: amitanand, skedia, myang
Reviewed By: skedia, myang
Subscribers: tverona, yql, bogdan
Differential Revision: https://phabricator.dev.yugabyte.com/D19621
1 task
jasonyb
pushed a commit
that referenced
this issue
Nov 23, 2024
Summary: Concurrent index creation enforces state changes where clients cannot be more than one state apart. The state is tracked by the catalog version, and it is enforced by making sure all clients are at the catalog version corresponding to the state change before moving on to the next state. Problem is, the catalog version we wait on does not necessarily correspond to the actual state change. The catalog version used for waiting uses the local catalog version, which is just +1 of the previous version. That is not accurate when other DDLs bump up the catalog version simultaneously. Fix with two parts: 1. wait on a proper catalog version: instead of using the local catalog version, fetch the master's catalog version after the previous state change commit, then wait on that version. The downside is that there is a time window between commit and fetching of master's catalog version such that we may end up waiting on a later version than necessary, but I didn't find an easy way to get the actual version corresponding to the commit, especially considering issue #5030. 1. avoid waiting on the backend that is running the CREATE INDEX: since we are now possibly waiting on catalog versions that are beyond the version that the CREATE INDEX is at, it becomes necessary to whitelist the backend running CREATE INDEX from being taken into consideration during the wait on backends catalog version request. This involves a lot of plumbing to send down that information. The info to identify the backend is the tserver UUID and backend PID. Some considerations: - setting the local catalog version to +1 is an existing optimization that should be reconsidered. If a concurrent DDL happened such that the actual catalog version is higher, this backend may pass breaking catalog version checks even if it doesn't deserve to. Do not deal with this issue in this commit. Filed #25068. - two callers of wait on backends catalog version for the same db+version is no longer as shareable because only one backend is excepted. Whichever caller was first will register their backend tserver/pid for exemption from the check. If a second caller has the same db+version, it will have to wait behind the existing information. It is not safe to add this second caller's tserver/pid for additional exemption because both callers can actually be waiting on different catalog versions, but they happened to pick up a later catalog version since the picking is not perfect right now. In that case, it is incorrect to ignore both backends in case the first caller was corresponding to an actual version later than the second caller's actual version. So such two-caller cases might end up conflicting on each other. Even if these two callers were not combined and instead got their separate jobs, they could still be waiting on each other if their CREATE INDEXes started on old versions. Jira: DB-13866 Test Plan: On Almalinux 8: ./yb_build.sh fastdebug --gcc11 \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh release \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh tsan \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 300 ./yb_build.sh fastdebug --gcc11 \ --cxx-test pg_backends-test Backport-through: 2.20 Reviewers: myang, amartsinchyk Reviewed By: amartsinchyk Subscribers: amartsinchyk, ybase, yql Differential Revision: https://phorge.dev.yugabyte.com/D39780
jasonyb
pushed a commit
that referenced
this issue
Dec 6, 2024
Summary: Concurrent index creation enforces state changes where clients cannot be more than one state apart. The state is tracked by the catalog version, and it is enforced by making sure all clients are at the catalog version corresponding to the state change before moving on to the next state. Problem is, the catalog version we wait on does not necessarily correspond to the actual state change. The catalog version used for waiting uses the local catalog version, which is just +1 of the previous version. That is not accurate when other DDLs bump up the catalog version simultaneously. Fix with two parts: 1. wait on a proper catalog version: instead of using the local catalog version, fetch the master's catalog version after the previous state change commit, then wait on that version. The downside is that there is a time window between commit and fetching of master's catalog version such that we may end up waiting on a later version than necessary, but I didn't find an easy way to get the actual version corresponding to the commit, especially considering issue #5030. 1. avoid waiting on the backend that is running the CREATE INDEX: since we are now possibly waiting on catalog versions that are beyond the version that the CREATE INDEX is at, it becomes necessary to whitelist the backend running CREATE INDEX from being taken into consideration during the wait on backends catalog version request. This involves a lot of plumbing to send down that information. The info to identify the backend is the tserver UUID and backend PID. Some considerations: - setting the local catalog version to +1 is an existing optimization that should be reconsidered. If a concurrent DDL happened such that the actual catalog version is higher, this backend may pass breaking catalog version checks even if it doesn't deserve to. Do not deal with this issue in this commit. Filed #25068. - two callers of wait on backends catalog version for the same db+version is no longer as shareable because only one backend is excepted. Whichever caller was first will register their backend tserver/pid for exemption from the check. If a second caller has the same db+version, it will have to wait behind the existing information. It is not safe to add this second caller's tserver/pid for additional exemption because both callers can actually be waiting on different catalog versions, but they happened to pick up a later catalog version since the picking is not perfect right now. In that case, it is incorrect to ignore both backends in case the first caller was corresponding to an actual version later than the second caller's actual version. So such two-caller cases might end up conflicting on each other. Even if these two callers were not combined and instead got their separate jobs, they could still be waiting on each other if their CREATE INDEXes started on old versions. Backport-note: resolve merge conflict in pg_index_backfill-test.cc due to lack of 77958e8. Jira: DB-13866 Test Plan: On Almalinux 8: ./yb_build.sh fastdebug --gcc11 \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh release \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh tsan \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 300 ./yb_build.sh fastdebug --gcc11 \ --cxx-test pg_backends-test Backport-through: 2.20 Original commit: 29076dd / D39780 Reviewers: amartsinchyk Reviewed By: amartsinchyk Subscribers: myang Differential Revision: https://phorge.dev.yugabyte.com/D40400
jasonyb
pushed a commit
that referenced
this issue
Dec 20, 2024
Summary: Concurrent index creation enforces state changes where clients cannot be more than one state apart. The state is tracked by the catalog version, and it is enforced by making sure all clients are at the catalog version corresponding to the state change before moving on to the next state. Problem is, the catalog version we wait on does not necessarily correspond to the actual state change. The catalog version used for waiting uses the local catalog version, which is just +1 of the previous version. That is not accurate when other DDLs bump up the catalog version simultaneously. Fix with two parts: 1. wait on a proper catalog version: instead of using the local catalog version, fetch the master's catalog version after the previous state change commit, then wait on that version. The downside is that there is a time window between commit and fetching of master's catalog version such that we may end up waiting on a later version than necessary, but I didn't find an easy way to get the actual version corresponding to the commit, especially considering issue #5030. 1. avoid waiting on the backend that is running the CREATE INDEX: since we are now possibly waiting on catalog versions that are beyond the version that the CREATE INDEX is at, it becomes necessary to whitelist the backend running CREATE INDEX from being taken into consideration during the wait on backends catalog version request. This involves a lot of plumbing to send down that information. The info to identify the backend is the tserver UUID and backend PID. Some considerations: - setting the local catalog version to +1 is an existing optimization that should be reconsidered. If a concurrent DDL happened such that the actual catalog version is higher, this backend may pass breaking catalog version checks even if it doesn't deserve to. Do not deal with this issue in this commit. Filed #25068. - two callers of wait on backends catalog version for the same db+version is no longer as shareable because only one backend is excepted. Whichever caller was first will register their backend tserver/pid for exemption from the check. If a second caller has the same db+version, it will have to wait behind the existing information. It is not safe to add this second caller's tserver/pid for additional exemption because both callers can actually be waiting on different catalog versions, but they happened to pick up a later catalog version since the picking is not perfect right now. In that case, it is incorrect to ignore both backends in case the first caller was corresponding to an actual version later than the second caller's actual version. So such two-caller cases might end up conflicting on each other. Even if these two callers were not combined and instead got their separate jobs, they could still be waiting on each other if their CREATE INDEXes started on old versions. Jira: DB-13866 Merge notes: - Remove ASSERT_OK around BumpCatalogVersion because of lack of commit 0f875f5. - Bring missing test class PgIndexBackfillReadCommittedBlockIndislive from commit 68f7de8 which was not backported here. - Bring missing indislive blocking (indexcmds.c, guc.c) from commit 68f7de8 which was not backported here. - Disable test in sanitizers because lack of 0f875f5 occasionally causes Bad status: Network error (yb/yql/pgwrapper/libpq_utils.cc:432): Fetch 'SELECT yb_increment_all_db_catalog_versions(true)' failed: 7, message: ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA (pgsql error XX000) (aux msg ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA) Test Plan: On Almalinux 8: ./yb_build.sh fastdebug --gcc11 \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh release \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh fastdebug --gcc11 \ --cxx-test pg_backends-test Backport-through: 2.20 Original commit: 29076dd / D39780 Reviewers: amartsinchyk Reviewed By: amartsinchyk Subscribers: pjain, myang Differential Revision: https://phorge.dev.yugabyte.com/D40815
jasonyb
pushed a commit
that referenced
this issue
Dec 23, 2024
Summary: Concurrent index creation enforces state changes where clients cannot be more than one state apart. The state is tracked by the catalog version, and it is enforced by making sure all clients are at the catalog version corresponding to the state change before moving on to the next state. Problem is, the catalog version we wait on does not necessarily correspond to the actual state change. The catalog version used for waiting uses the local catalog version, which is just +1 of the previous version. That is not accurate when other DDLs bump up the catalog version simultaneously. Fix with two parts: 1. wait on a proper catalog version: instead of using the local catalog version, fetch the master's catalog version after the previous state change commit, then wait on that version. The downside is that there is a time window between commit and fetching of master's catalog version such that we may end up waiting on a later version than necessary, but I didn't find an easy way to get the actual version corresponding to the commit, especially considering issue #5030. 1. avoid waiting on the backend that is running the CREATE INDEX: since we are now possibly waiting on catalog versions that are beyond the version that the CREATE INDEX is at, it becomes necessary to whitelist the backend running CREATE INDEX from being taken into consideration during the wait on backends catalog version request. This involves a lot of plumbing to send down that information. The info to identify the backend is the tserver UUID and backend PID. Some considerations: - setting the local catalog version to +1 is an existing optimization that should be reconsidered. If a concurrent DDL happened such that the actual catalog version is higher, this backend may pass breaking catalog version checks even if it doesn't deserve to. Do not deal with this issue in this commit. Filed #25068. - two callers of wait on backends catalog version for the same db+version is no longer as shareable because only one backend is excepted. Whichever caller was first will register their backend tserver/pid for exemption from the check. If a second caller has the same db+version, it will have to wait behind the existing information. It is not safe to add this second caller's tserver/pid for additional exemption because both callers can actually be waiting on different catalog versions, but they happened to pick up a later catalog version since the picking is not perfect right now. In that case, it is incorrect to ignore both backends in case the first caller was corresponding to an actual version later than the second caller's actual version. So such two-caller cases might end up conflicting on each other. Even if these two callers were not combined and instead got their separate jobs, they could still be waiting on each other if their CREATE INDEXes started on old versions. Jira: DB-13866 Merge notes: - Remove ASSERT_OK around BumpCatalogVersion because of lack of commit 0f875f5. - Bring missing test class PgIndexBackfillReadCommittedBlockIndislive from commit 68f7de8 which was not backported here. - Bring missing indislive blocking (indexcmds.c, guc.c) from commit 68f7de8 which was not backported here. - Disable test in sanitizers because lack of 0f875f5 occasionally causes Bad status: Network error (yb/yql/pgwrapper/libpq_utils.cc:432): Fetch 'SELECT yb_increment_all_db_catalog_versions(true)' failed: 7, message: ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA (pgsql error XX000) (aux msg ERROR: The catalog snapshot used for this transaction has been invalidated: expected: 2, got: 1: MISMATCHED_SCHEMA) - Use PgIndexBackfillTestEnableWait subclass to enable backends manager (this should be the case in master for future-proofing, but it is minor and not worth the hassle) - Use FetchValue instead of FetchRow (see commit 4ec5f1c). Test Plan: On Almalinux 8: ./yb_build.sh fastdebug --gcc11 \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh release \ --gtest_filter PgIndexBackfillTest.CatVerBumps \ -n 100 ./yb_build.sh fastdebug --gcc11 \ --cxx-test pg_backends-test Backport-through: 2.20 Original commit: 29076dd / D39780 Reviewers: amartsinchyk Reviewed By: amartsinchyk Subscribers: myang, pjain Differential Revision: https://phorge.dev.yugabyte.com/D40838
1 task
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Jira Link: DB-2503
During YSQL index backfill process, in
indexcmds.cwe're doing this:We expect
YBDecrementDdlNestingLevelto makepg_indexrow (withindislive=true) to become visible to master forYBCPgAsyncUpdateIndexPermissions, but in the logs we see:(i.e.
ShouldProceedWithPgsqlIndexPermissionUpdateinbackfill_index.ccdid not find the row inpg_index)To reproduce, enable YSQL backfill and run
(logs)
UPD:
Same issue with
TestPgRegressMisc(logs),TestPgRegressPlanner(logs), and many otherTestPgRegress*testsThe text was updated successfully, but these errors were encountered: