From ed35e21a585a4f8292c792e514bb4d023b88089e Mon Sep 17 00:00:00 2001 From: Annpurna Shahani Date: Thu, 16 May 2024 17:26:35 +0530 Subject: [PATCH] [7X] Removed redundant tests Following gprecoverseg scenarios are not valid- * SIGINT on gprecoverseg should delete the progress file * SIGINT on gprecoverseg differential recovery should delete the progress file Reason: if user selects yes when prompted for input at the time of interrupt, gprecoverseg will be terminated and segments will still be down. If user selects no, then recovery will continue marking the segments up but progress file will exist. Hence above scenarios are invalid. Assertion of progress file deletion has been covered already in following scenario: * gprecoverseg should terminate on SIGINT when user selects Yes in the prompt --- .../behave/mgmt_utils/gprecoverseg.feature | 23 ------------------- 1 file changed, 23 deletions(-) diff --git a/gpMgmt/test/behave/mgmt_utils/gprecoverseg.feature b/gpMgmt/test/behave/mgmt_utils/gprecoverseg.feature index cd9599a42a1..55fd42d070a 100644 --- a/gpMgmt/test/behave/mgmt_utils/gprecoverseg.feature +++ b/gpMgmt/test/behave/mgmt_utils/gprecoverseg.feature @@ -629,29 +629,6 @@ Feature: gprecoverseg tests And user can start transactions And all files in gpAdminLogs directory are deleted on all hosts in the cluster - @demo_cluster - @concourse_cluster - Scenario: SIGINT on gprecoverseg should delete the progress file - Given the database is running - And all the segments are running - And the segments are synchronized - And all files in gpAdminLogs directory are deleted on all hosts in the cluster - And user immediately stops all primary processes for content 0,1,2 - And user can start transactions - And sql "DROP TABLE IF EXISTS test_recoverseg; CREATE TABLE test_recoverseg AS SELECT generate_series(1,100000000) AS a;" is executed in "postgres" db - And the user suspend the walsender on the primary on content 0 - When the user asynchronously runs "gprecoverseg -aF" and the process is saved - Then the user waits until recovery_progress.file is created in gpAdminLogs and verifies its format - Then verify if the gprecoverseg.lock directory is present in coordinator_data_directory - When the user asynchronously sets up to end gprecoverseg process with SIGINT - And the user waits until saved async process is completed - Then recovery_progress.file should not exist in gpAdminLogs - Then the user reset the walsender on the primary on content 0 - Then the gprecoverseg lock directory is removed - And the user waits until mirror on content 0,1,2 is up - And verify that lines from recovery_progress.file are present in segment progress files in gpAdminLogs - And the cluster is rebalanced - @demo_cluster @concourse_cluster Scenario: SIGHUP on gprecoverseg should not display progress in gpstate -e