[ 
https://issues.apache.org/jira/browse/IGNITE-18377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17647589#comment-17647589
 ] 

Ignite TC Bot commented on IGNITE-18377:
----------------------------------------

{panel:title=Branch: [pull/10441/head] Base: [master] : Possible Blockers 
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests 
10|https://ci.ignite.apache.org/viewLog.html?buildId=6963202]]
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestDiscoveryWithoutClientConnectorOnServer
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestClientMaintainsConnectionWhenOriginalNodeLeaves
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestClientDiscoveryWithRandomTopologyChanges
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestThinClientDoesNotDiscoverThickClientNodes
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: 
ClientClusterDiscoveryTestsNoLocalhost.TestClientDiscoversJoinedServersAndRemovesDisconnected
 - Test has low fail rate in base branch 0,0% and is not flaky
* exe: IgnitionStartTest.TestIgniteStartsFromAppConfig - Test has low fail rate 
in base branch 0,0% and is not flaky
* exe: IgniteConfigurationSectionTest.TestIgniteStart - Test has low fail rate 
in base branch 0,0% and is not flaky
* dll: EntityFrameworkCacheInitializationTest.TestConfigurationAndStartup - 
Test has low fail rate in base branch 0,0% and is not flaky
* exe: IgniteStartStopTest.TestStartDefault - Test has low fail rate in base 
branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/10441/head] Base: [master] : New Tests 
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#00008b}Queries 4{color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963081]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite4: 
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance - 
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite4: 
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance - 
PASSED{color}

{color:#00008b}Queries 4 (lazy=true){color} [[tests 
2|https://ci.ignite.apache.org/viewLog.html?buildId=6963082]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4: 
SqlQueriesTopologyMappingTest.testReplicatedQueryStatUpdateWithRebalance - 
PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite4: 
SqlQueriesTopologyMappingTest.testPartitionedQueryStatUpdateWithRebalance - 
PASSED{color}

{panel}
[TeamCity *--> Run :: All* 
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6963105&buildTypeId=IgniteTests24Java8_RunAll]

> Sql statistics become broken after node restart with enabled persistence.
> -------------------------------------------------------------------------
>
>                 Key: IGNITE-18377
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18377
>             Project: Ignite
>          Issue Type: Bug
>          Components: sql
>    Affects Versions: 2.14
>            Reporter: Evgeny Stanilovsky
>            Assignee: Evgeny Stanilovsky
>            Priority: Major
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> It tuned out that for some reasons SQL query may be dispatched to data node 
> which is performing rebalance. Eventually this will lead to falling back to 
> full table scan usage instead of proper tree index.
> Scenario:
> 1. Cluster in normal state with multiple nodes, under workload (both cache 
> writes/updates and SQL selects)
> 2. Particular node A is restarted
> 3. Since there were writes during the time when node A was offline, node A 
> would has to perform historical rebalance
> 4. During performing historical rebalance SQL select might be dispatched to 
> be executed on node A as well, but at this moment node A will return 0 
> primary row count for caches under rebalance, so we will initialize table 
> statistics incorrectly and further will calculate unrealistic costs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to