# Copyright (C) 2019, 2022 MariaDB corporation Ab. All rights reserved. Use # is subject to license terms. # # This program is free software; you can redistribute it and/or modify # it under the terms of the GNU General Public License as published by # the Free Software Foundation; version 2 of the License. # # This program is distributed in the hope that it will be useful, but # WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU # General Public License for more details. # # You should have received a copy of the GNU General Public License # along with this program; if not, write to the Free Software # Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 # USA use GenTest::Grammar; # Configuration file template for using rqg_batch.pl for simplifying RQG tests # # Please # - Copy this file to for example 1.cfg and # - Adjust the settings so that they fit to your use case and environment. # # # Anything which is relevant for the simplification process itself # == lib/Simplify.pm needs to know that # must or should be on top level and not nested into 'rqg_options'. # { # The verdict setup #------------------ # Lists of # desired results --> *_replay # unwanted results --> *_unwanted # RQG exit statuses --> statuses_* # text patterns in RQG log --> patterns_* # which allows the RQG tool rqg_batch.pl to # - get a verdict if some RQG run replayed the result defined by that or not # - classify test results # - decide how proceed. # # What counts here is getting # a) Verdict::RQG_VERDICT_REPLAY ('replay') # == We had a full whitelist match and no partial or full blacklist match. # b) Verdict::RQG_VERDICT_INTEREST ('interest') # == We hit some bad result but neither a full whitelist match nor a partial or full # blacklist match. # c) Verdict::RQG_VERDICT_IGNORE_STATUS_OK => 'ignore_status_ok'; # == We hit a 'pass' and neither a full or partial whitelist match nor a partial or # full blacklist match. # d) Verdict::RQG_VERDICT_IGNORE_BLACKLIST => 'ignore_blacklist'; # == We had a full or partial blacklist match. # # The generation of the final verdict setup # 1. /verdict_general.cfg gets loaded first. # It contains the main amount of statuses and text patterns. # Main purpose: Define text patterns ($patterns_*) for result classification. # Secondary purpose: # Define unwanted test results via text patterns ($patterns_ignore) and use that for # a) likely speedup of simplification # Example: # A simplification attempt removing a YY grammar line and causing some unwanted result # is probably a step into some unfortunate direction. Therefore giving other simplification # attempts a higher weight (-> more trials) makes sense. # Per current experience the serious amount of unwanted text patterns in verdict_general.cfg # makes this approach useful. And at least some of the patterns help to avoid risky states # at simplification runtime. # b) Do not archive such results. # Archiving of results during test simplification runs is usually not recommended at all. # It costs significant resources and hereby simplification speed. # In the rather rare case of "misusing" a simplification run for catching arbitrary bugs # including getting rr traces omitting the archiving of some results is highly recommended. # 2. The verdict setup fragments between the "Section Verdict setup ------- start/end" lines # get loaded second and override the settings from verdict_general.cfg in case of duplicate key. # Example: # verdict_general.cfg might define that # 'TBR-99', '' # is of interest or unwanted. # The simplifier setup can redefine that getting counts as 'replay'. # Please note that the key is the value of the text pattern and not the classification. # Basically the verdict setup fragments here # - define the goal of the simplification via setting *_replay # - could give some hints by defining further unwanted results # # # 'Unsharp' (the pattern is already unsharp or there is more than one element in the list) : # Example1: # # A lot Innodb asserts get matched by this pattern. # [ 'InnoDB assert' , 'mysqld:.{1,150}innobase.{1,1000} Assertion .{1,500} failed.' ], # Example2 of replay patterns (TBR = To be reported and in the moment in focus): # [ 'TBR-1' , 'InnoDB: Failing assertion: \!cursor->index->is_committed\(\)' ], # [ 'TBR-2' , 'mysqld: .{1,150}data0data.h:.{1,20} dfield_t. dtuple_get_nth_field.{1,30}: Assertion .n < tuple->n_fields. failed.' ], # [ 'TBR-3' , 'mysqld: .{1,150}lock0lock.cc.{1,20} my_bool lock_rec_other_trx_holds_expl_callback.{1,150}: Assertion .\!expl_lock \|\| expl_lock->trx == arg->impl_trx. failed.' ], # [ 'TBR-4' , 'mysqld:.{1,200}btr0cur.cc:.{1,30}dberr_t btr_cur_search_to_nth_level_func.{1,500} failed' ], # The basic approach/logics of such a setup is: # I do not care for which assert I get a simplified test first. # # Advantage: # The simplifier run will result in (artificial example related to Example2 above): # The simplification starts with grammar table_stress.yy which gets transformed to p0.yy # and delivers a series of grammars p*.yy and final.yy. # Smallest replaying grammar (final.yy) -- TBR-3 # There are bigger grammars replaying TBR-3 but they could be ignored. # Smallest grammar replaying TBR-1 is p.yy (but bigger than final.yy). # It is to be expected that this grammar could also replay TBR-3. # Smallest grammar replaying TBR-2 is p.yy (but bigger than p.yy). # It is to be expected that this grammar could also replay TBR-3 and TBR-1. # ~ Grammar size/complexity: p0.yy > p.yy > p.yy > final.yy # TBR-4 does not get replayed from reasons like # - grammar is not capable to replay it at all # - TBR-4 is fixed # # How to go on: # Manual simplification etc. for TBR-3 based on final.yy or the p.yy with highest . # Move the pattern for TBR-3 from patterns_replay to patterns_unwanted. # Restart the grammar simplification for TBR-1 based on p.yy. # Manual simplification etc. for TBR-1 based on the new final.yy. # ... # The win is that the simplification for TBR-1 does not start with table_stress.yy # which is serious more complex than p.yy. And that saves a lot elapsed time. # Disadvantage: # No control over for which bug you get full simplification first. # But its quite likely that the best replayable bug will get full simplification first # compared to the other. # # Hints: # Have a ',' at the end of each element definition even if its the last one. # # Section Verdict setup ---------------------------------------------------------------------- start # # # Regarding statuses: # # The complete list of statuses is in lib/GenTest/Constants.pm. # # Just the most important ones: # # STATUS_SERVER_DEADLOCKED STATUS_REPLICATION_FAILURE # # STATUS_VALGRIND_FAILURE STATUS_BACKUP_FAILURE # # STATUS_RECOVERY_FAILURE STATUS_ENVIRONMENT_FAILURE # # STATUS_ALARM(RQG core sees problem but has no idea why) # # STATUS_SERVER_CRASHED STATUS_DATABASE_CORRUPTION # # STATUS_ANY_ERROR(any status != STATUS_OK) # # We do no more take the exit status of the process running RQG because of technical reasons. # # The status is taken from a line containing # # 'RESULT: The RQG run ended with status ' # # and written direct after finishing GenTest into the log of the RQG run. # # $statuses_replay = # [ # # [ 'STATUS_ANY_ERROR' ], # [ 'STATUS_SERVER_CRASHED' ], # ]; # # # # DO NOT ADD ENTRIES HERE EXCEPT YOU KNOW THE IMPACT. # $statuses_interest = # [ # ]; # # # $statuses_ignore = # [ # ]; # # # # Regarding text patterns: # # The search patterns are often derived from an assert or a backtrace found in the log of some # # historic RQG run. # # Example: # # Starting point is a crash of a server which was compiled with debug. # # A text patterns could match a group of lines. # # 'assert.{0,150}safe_cond_timedwait.{0,150}thr_mutex\.c.{0,50}Item_func_sleep::val_int.{0,3000}SELECT 1,SLEEP\(10\)' # # # # Please be careful when using # # - characters with special meaning in pattern matching like +?.*^$()[]{}|\` # # Use '\' in order to disable the special meaning or just replace any suspicious character # # by a '.' in case the pattern is already selective enough. # # - memory addresses or source code line numbers # # They are brilliant selective but might stop to work after the next pull source + compile. # # Bad example: # # 'mysqld: .{1,150}btr0cur.cc:.{1,20} dberr_t btr_cur_search_to_nth_level_func.{1,300}: Assertion `rw_lock_own\(dict_index_get_lock\(index\), RW_LOCK_S\)\' failed.', # # causes a bit output by rqg_batch.pl and sh 1: EOF in backquote substitution | # # / \ # # $patterns_replay = # [ # [ 'MDEV-17843', 'mysqld: .{1,150}lock0lock.cc:.{1,30} bool lock_rec_queue_validate\(.{1,250}\): Assertion .page_rec_is_leaf\(rec\). failed.' ], # ]; # # # DO NOT ADD ENTRIES HERE EXCEPT YOU KNOW THE IMPACT. # $patterns_interest = # [ # ]; # # # # Adding entries here might increase the simplification speed a bit. # # But its most probably not worth the time required for editing. # $patterns_ignore = # [ # ]; # # Section Verdict setup ------------------------------------------------------------------------ end # simplify_mode defines how rigid the test simplification should be tried. # ------------------------------------------------------------------------ # 'simp_mode_soft' # Simplifications which imply the risk to maybe change the semantics of the test should # be not tried. # Examples of contra indications (better use 'simp_mode_destructive' because its faster): # We are hunting for an assert, SEGV, ASAN error or similar. # simplify_mode => 'simp_mode_soft', # # 'simp_mode_destructive' # Simplifications which imply the risk to maybe change the semantics of the test are allowed. # Examples (some might be not yet implemented): # a) rule1: | ; --> rule1: ; # b) rule2: ; ; --> rule2: ; # c) rule3: --> rule3: # SELECT col1 FROM t1 SELECT col1 FROM t1 | # WHERE col3 = 13 | ; # ; # Examples of contra indications (better use 'simp_mode_soft'): # - We have queries consisting of several SQLs followed by validation. # 'simp_mode_destructive' might destruct one or more of these SQLs and than we might get # false positives if the validator is not prepared for that case. # - Threads maintain entries in some table and kill each other based on the content of # that table. In case that maintenance is partial harmed than the replay likelihood could # decrease drastic. # - rule1: LOCK TABLE ... ; { sleep 5; return undef } UNLOCK ... gets simplified to # rule1: LOCK TABLE ... ; # Could it happen that the reporter "Deadlock" kicks in? And if 'yes' what if we were # hunting for a server 'freeze'? # - Partially surprising uncomfortable effects during manual grammar simplification later. # For example # - a column named col_int is now of data type VARCHAR(200). # - query generation starting with the rule query might set a variable $a to some value. # Some query generation later might use $a but not set $a before. # Default: 'simp_mode_destructive' simplify_mode => 'simp_mode_destructive', # simplify_chain defines which test simplification steps/phases should be executed and # in which order. simplify_chain => [ #### PHASE_FIRST_REPLAY #### # Attempt to replay with the compactified initial grammar. # Main purpose: # Check if the whitelist/blacklist statuses/patterns fit because otherwise the # simplification run is valueless. No replay within $trial finished attempts leads to # abort of simplification process. # In case you are believing (*) that the list setup is good # - than you can save some (usually a few minutes up till 0.5h (**)) of the total # simplifier runtime by omitting this phase. # - and fear that $trials might be too small for replaying and also hesitate to # increase $trials from whatever reason than omitting this phase gives you # roughly endless trials on different minimal simplified grammars. # Default: 'first_replay' enabled and first phase. 'first_replay', # #### PHASE_THREAD1_REPLAY #### # Attempt to replay with the actual best (usually the compactified initial) grammar # and threads = 1. # Main purpose: # Check if the desired outcome might be a single user effect. # If yes we can # - apply some simplifications depending on grammar content # ==> reduce complexity # ==> (hopefully) speedup of simplification process which maybe follows # or # - also bail out (corresponding functionality is currently missing). # ==> Setup (manually) mysqltest simplification and start that. # mysqltest simplification is usually serious faster but the manual setup costs # frequent serious efforts. # In case you are believing (*) that its a concurrency problem than you can save some # (usually a few minutes up till 0.5h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'thread1_replay' enabled and second phase. # 'thread1_replay', # #### PHASE_RVT_SIMP #### # Attempt to shrink the amount of reporters, validators, transformers. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification phases which maybe follow. # In case you are believing (*) that the reporters, validators, transformers used are # either required or do not consume significant runtime than you can save some # (usually a few minutes up till 1h (**)) of the total simplifier runtime by # omitting this phase. # Default: 'rvt_simp' enabled and third phase. # 'rvt_simp', # #### PHASE_GRAMMAR_SIMP #### # Attempt to shrink (remove components of grammar rules, inline rules etc.) the actual best # replaying grammar. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification process which maybe follows. # Default: 'grammar_simp' enabled and fourth phase. 'grammar_simp', # #### PHASE_THREAD_REDUCE ### # Attempt to reduce the number of involved threads/connections. # Main purpose: # Reduce complexity and (hopefully) speedup of simplification phases which maybe follow. # Default: 'thread_reduce' enabled and fifth phase. # # It is highly recommended to not omit this phase in case PHASE_GRAMMAR_CLONE follows. # 'thread_reduce', # #### PHASE_GRAMMAR_CLONE ### # Attempt to transform the grammar by cloning of more than once used rules. # In case that leads to some different grammar the phase "grammar_simp" gets repeated. # Example: # Original grammar =========> Transformed grammar # rule1: rule1: # SELECT where | SELECT __clone_1 | # UPDATE where ; UPDATE __clone_2 ; # where: __clone_1: # WHERE col1 = 2 | WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; WHERE col2 BETWEEN 3 AND 7; # __clone_2: # WHERE col1 = 2 | # WHERE col2 BETWEEN 3 AND 7; # # In case that is leading to some grammar which differs from the current best one than # grammar simplification is tried (Repetition of PHASE_GRAMMAR_SIMP described above.) # # Main purposes ordered by likelihood that they happen: # 1. Faster replay of the problem, faster manual simplification faster bug fixing. # But also longer (up to a few hours) lasting "automatic" simplification. # 2. Have some serious better distribution of statement generation over concurrent # threads/sessions. # Example: # Let's assume in the original grammar # - many threads use "query" as top entry # - "query" generates a broad range of DDL and DML # Depending on the case bug fixers frequent prefer if only a few sessions run # DDL but no DML or only ALTER .... at all and similar. # When enabling the simplification step 'grammar_clone' than its serious more # likely that we finally end up with some more extreme distribution. # This provides also some serious better base for developing some replay test based # on my shellscript "mysqltest_background.sh" and MTR as tool. # == Replay without the rapid changing and rather heavy RQG infrastructure. # 3. The final grammar generates less different SQL. # # Please note that the first parent grammar after cloning does not generate # - different SQL in general # - some different distribution or frequency of SQL # Negative example: thread1 runs now UPDATEs at all or more than previous. # than the previous parent grammar. # But the new parent grammar might have a several times bigger amount of lines. # Default: 'grammar_clone enabled and fifth phase. 'grammar_clone', # #### PHASE_FINAL_REPLAY #### # Attempt to replay with the final simplified test. # Main purpose: # Check how fast some replay could be achieved with that setup and YY grammar. # Default: 'final_replay' enabled and last phase. 'final_replay' # (*) Its not that likely that mistakes have a dramatic bad impact. # (**) The time range mentioned is nothing else than some qualified guess based on # experiences. The range depends on $trials, $parallel, how likely the effect you # are simplifying for shows up etc. # At runtime its quite often like # - Saving a few hours looks on the first view impressing but the total simplification # runtime was even without that more than 30 hours. So the win is often <= 10%. # - If partially manual working on some already automatic simplified test including # "active" waiting for results the omitting of no more required simplification # steps could safe serious working time. # ], # grammar_file #------------- # File which should be used as the base for the simplification process. # It should be an "effective" YY grammar == # - grammar + redefine files are already merged/joined # - any masking was already applied # # Recommendation: # Think about setting '--grammar=......' via command line option like # # perl rqg_batch.pl ... --grammar= # # This will override any setting of grammar in the config file # - top level section # - "rqg_options" section # # grammar => 'conf/mariadb/table_stress.yy', grammar => 'MDEV-17843.yy', # redefine files #--------------- # Do not set redefine files here or in the rqg_options section because the RQG test simplifier will # ignore them! # # threads => 10, threads => 2, queries => 10000000, # duration and duration_adaption # ------------------------------ # duration assigned to some RQG runner like rqg.pl # == Maximum YY grammar processing time. # duration assigned to rqg_batch.pl # == A value used for computing the duration assigned to some RQG run. # Default: 300 seconds duration => 300, # # duration_adaption == which function to use for adapting the duration assigned to RQG runs # # duration_adaption value for duration assigned to the next RQG run started # 'None' duration (here) == No adaption at all. # Have a fifo containing the real (*) YY grammar processing times of the last 10 replaying RQG # runs. (*) If value measured > duration (here) than only charge duration (here). # 'Maximum' Minimum of (duration (here), maximum(fifo)) # 'MaximumMiddle' (duration (here) + maximum(fifo)) / 2 # 'Experimental' Some value computed based on formula for Gaussian distribution (**). # (**) We have definitely not a Gaussian distribution but the formula # delivers quite usable values. # This is the default. duration_adaption => 'Experimental', # Hints about how to speed up especially the simplification process # 1. Add 'None' to the list of reporters and validators in case you are sure that you do not # need stuff added per default. # 2. In case you simplify for whitelist_patterns matching messages written by the server or # other tools # Example: 'InnoDB: Failing assertion: opt_no_lock' # and not for parts of backtraces than use the reporter 'ServerDead' instead of 'Backtrace'. # The gain in simplification speed will be > 50%. # 3. As long as certain open bugs about server freezes are not fixed and frequent used grammars # will replay them frequent please add the reporter # 'Deadlock1', # even if not searching for these freezes. # RQG tests which have no more a chance to replay what you are searching for will get # earlier detected and terminated. reporters => [ 'Deadlock1', 'ErrorLog', 'Backtrace', ], validators => [ 'None', ], transformers => [ # Do not assign here a 'None'. Otherwise RQG will abort. ], # Do NOT assign basedirs etc. here # rqg_options #------------ # rqg.pl (RQG runner) options which should be used # Warning: # You can define threads, validators etc. also within the RQG option block. # But please be aware that any setting != 0, undef or '' being outside like # - outside of the rqg_options block within the config file # - within the rqg_batch.pl call # will be glued to the end of the final RQG call line and hereby "win". # rqg_options => { engine => 'InnoDB', # Generation of initial data via 'gendata', 'gendata-advanced' or zz file # ----------------------------------------------------------------------- # In case you do not want that whatever kind of gendata happens than set the following skip_gendata => undef, # # gendata => undef, # gendata-advanced => undef, # # gendata => 'conf/mariadb/table_stress.zz', # Some of the gendata variants support options # short_column_names => undef, # views => undef, # vcols => undef, # # Generation of initial data via SQL script (mysql and not mysqltest style) # ------------------------------------------------------------------------- gendata_sql => 'conf/mariadb/table_stress.sql', # Raise the limit for the maximum gendata runtime if more than default required # ----------------------------------------------------------------------------- max_gd_duration => '1200', # Replicate with various methods (rpl_mode) # ----------------------------------------- # RQG_RPL_NONE # Run with one server only. No replication of any type at all. rpl_mode => 'none', # # RQG_RPL_STATEMENT # Run with two servers, MariaDB replication and binlog_format=statement. # rpl_mode => 'statement', # RQG_RPL_STATEMENT_NOSYNC # rpl_mode => 'statement-nosync', # # RQG_RPL_MIXED # Run with two servers, MariaDB replication and binlog_format=mixed. # rpl_mode => 'mixed', # RQG_RPL_MIXED_NOSYNC # rpl_mode => 'mixed-nosync', # # RQG_RPL_ROW # Important observation: # 10.4 -> 10.3 failed systematic with Error_code: 1032; handler error HA_ERR_END_OF_FILE # 10.4 -> 10.4 worked # 10.3 -> 10.4 worked # Run with two servers, MariaDB replication and binlog_format=row. # rpl_mode => 'row', # RQG_RPL_ROW_NOSYNC # rpl_mode => 'row-nosync', # # RQG_RPL_GALERA # Unclear if currently used. # Run with n? servers and Galera # rpl_mode => 'galera', # # RQG_RPL_RQG2 # Run with two servers and RQG's builtin statement based replication. # rpl_mode => 'rqg2', # RQG_RPL_RQG3 # Run with three servers and RQG's builtin statement based replication. # rpl_mode => 'rqg3', # # sqltracing by RQG # ----------------- # Advantage: # The RQG log content gives you at least some idea which SQL was running when some # replay happened. # Disadvantage: # Higher resource consumption during runtime of the simplifier. # Getting at least some idea which SQL was running when some replay happened isn't bad # but quite frequent such information does not help significant or only a few (the # last ones) statements are already sufficient. This means logging all previous only # wasted resources). # I recommend to # - not enable sqltracing here # - perform runs with sqltracing after simplification end if useful at all. # # Print trace message before sending the statement to the server. # sqltrace => undef, # Print trace message after receiving the result or error messages from the server # including error message etc. # sqltrace => 'MarkErrors', # mysqld => { # Some hints # ---------- # 1. Use 'loose_'. # 2. Feel free to use the environment variable RQG_HOME in assignments like # 'loose-file-key-management-filename' => '$RQG_HOME/conf/mariadb/encryption_keys.txt', # because rqg_batch.pl sets that variable before forking the RQG runner. # 'loose-max-statement-time' => '30', 'loose-innodb_read_only_compressed' => 'OFF', # Frequent used page_size buffer_pool combinations # ------------------------------------------------ # Extreme Stress (better for certain bugs) # 'innodb_page_size' => '4K', # 'innodb-buffer-pool-size' => '5M', # # 'innodb_page_size' => '8K', # 'innodb-buffer-pool-size' => '8M', # # 'innodb_page_size' => '16K', # 'innodb-buffer-pool-size' => '8M', # # 'innodb_page_size' => '32K', # 'innodb-buffer-pool-size' => '24M', # # 'innodb_page_size' => '64K', # 'innodb-buffer-pool-size' => '24M', # # Low Stress (faster gendata) # 'innodb_page_size' => '4K', # 'innodb-buffer-pool-size' => '256M', # # 'innodb_page_size' => '8K', # 'innodb-buffer-pool-size' => '256M', # # 'innodb_page_size' => '16K', # 'innodb-buffer-pool-size' => '256M', # # 'innodb_page_size' => '32K', # 'innodb-buffer-pool-size' => '256M', # # 'innodb_page_size' => '64K', # 'innodb-buffer-pool-size' => '256M', # 'innodb_adaptive_hash_index' => 'off', # 'innodb_stats_persistent' => 'off', 'loose-innodb_fatal_semaphore_wait_threshold' => 300, # 'loose-innodb_flush_log_at_trx_commit' => '0', # 'loose-innodb_file_per_table' => '0', # 'loose-innodb-sync-debug' => undef, # Avoid hitting https://jira.mariadb.org/browse/MDEV-16664 'loose_innodb_lock_schedule_algorithm' => 'fcfs', # # In some environment with many parallel RQG runs the following settings are required # for reducing trouble caused by # - shortages of resources # or # - slow responses of clients and servers. # IMHO it is recommended to set values even if the current defaults are already good # enough. Defaults could ge changed in future and than maybe to some unfortunate # direction. # ====================================================================================== # aio is on most boxes/OS a very short resource. # # Some older Ubuntu (default install): /proc/sys/fs/aio-max-nr is 65536 # MariaDB 10.5, ~ default setup of DB server # ~ 16 DB server run with aio. All other try to enable it too, fail and fall back to not # using aio. # There might be older MariaDB versions which do not have the fall back. # # 'loose_innodb_use_native_aio' => 0, # # rr+InnoDB running on usual filesystem on HDD or SSD need fsync. # Otherwise already bootstrap fails. # But the use of rr during simplification is NOT recommended because of the speed loss. # 'innodb_flush_method' => 'fsync', # # # Threads running the queries from YY grammar might frequent lose their connection # (get killed by other threads or reporters or commit/rollback release) and than need to # 1. connect again # 2. run a few initial SQL's before running the mass of YY grammar queries goes on # And in case 1. or 2. fails the RQG core tends to claim STATUS_SERVER_CRASHED, # STATUS_SERVER_CRASHED, STATUS_ENVIRONMENT_FAILURE and similar. This is often a false # alarm in case the timeouts are too short for some heavy loaded box. # 1. Is often a victim of connection related timeouts. # 2. Is often a victim of locking related timeouts and depending on the functionality # within the RQG core we get either some immediate end of the RQG run with # questionable status or the test goes on but the thread has not done things which # are mandatory for the test to work proper. In the second case we could end up with # false positives and similar. # Per my experience the innodb lock and MDL lock timeouts are quite critical. # In case the threads should use small values for these timeout during YY grammar # processing than these timeouts could be set in the rules # query_connect or # thread_connect # of the YY grammar. # # connect_timeout # Time in seconds that the server waits for a connect packet before returning a # 'Bad handshake'. Increasing may help if clients regularly encounter # 'Lost connection to MySQL server at 'X', system error: error_number' type-errors. # Default: 10 'connect_timeout' => 60, # # net_read_timeout # Time in seconds the server will wait for a client connection to send more data before # aborting the read. # Default: 30 'net_read_timeout' => 30, # # net_write_timeout # Time in seconds to wait on writing a block to a connection before aborting the write. # Default: 60 'net_write_timeout' => 60, # # idle_readonly_transaction_timeout # Time in seconds that the server waits for idle read-only transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_readonly_transaction_timeout' => 0, # # idle_transaction_timeout # Time in seconds that the server waits for idle transactions before killing the # connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_transaction_timeout' => 0, # # idle_write_transaction_timeout # Time in seconds that the server waits for idle read-write transactions before killing # the connection. If set to 0, the default, connections are never killed. # Default Value: 0 'loose-idle_write_transaction_timeout' => 0, # # innodb_lock_wait_timeout # Time in seconds that an InnoDB transaction waits for an InnoDB row lock (not table # lock) before giving up with the error # ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting trans... # When this occurs, the statement (not transaction) is rolled back. The whole # transaction can be rolled back if the innodb_rollback_on_timeout option is used. # Increase this for data warehousing applications or where other long-running operations # are common, or decrease for OLTP and other highly interactive applications. # This setting does not apply to deadlocks, which InnoDB detects immediately, rolling # back a deadlocked transaction. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: 50 'innodb-lock-wait-timeout' => 50, # # interactive_timeout # Time in seconds that the server waits for an interactive connection (one that connects # with the mysql_real_connect() CLIENT_INTERACTIVE option) to become active before # closing it. # Default Value: 28800 # AFAIK RQG will not initiate such connections. 'interactive_timeout' => 28800, # # lock_wait_timeout # Timeout in seconds for attempts to acquire metadata locks. Statements using metadata # locks include FLUSH TABLES WITH READ LOCK, LOCK TABLES, HANDLER and DML and DDL # operations on tables, stored procedures and functions, and views. The timeout is # separate for each attempt, of which there may be multiple in a single statement. # 0 (from MariaDB 10.3.0) means no wait. See WAIT and NOWAIT. # Default Value: # 86400 (1 day) >= MariaDB 10.2.4 # 31536000 (1 year) <= MariaDB 10.2.3 'lock-wait-timeout' => 86400, # # table_lock_wait_timeout # Unused, and removed in MariaDB/MySQL 5.5.3 # Default Value: 50 # IMHO its better to set it because we do not know which MariaDB version RQG might meet. 'loose-table_lock_wait_timeout' => 50, # # wait_timeout # Time in seconds that the server waits for a connection to become active before # closing it. The session value is initialized when a thread starts up from either the # global value, if the connection is non-interactive, or from the interactive_timeout # value, if the connection is interactive. # Default Value: 28800 'wait_timeout' => 28800, # # slave_net_timeout # Time in seconds for the slave to wait for more data from the master before considering # the connection broken, after which it will abort the read and attempt to reconnect. # The retry interval is determined by the MASTER_CONNECT_RETRY open for the # CHANGE MASTER statement, while the maximum number of reconnection attempts is set by # the master-retry-count variable. # The first reconnect attempt takes place immediately. # Default Value: # 60 (1 minute) (>= MariaDB 10.2.4) # 3600 (1 hour) (<= MariaDB 10.2.3) 'slave_net_timeout' => 60, # # # This makes the simplification process faster. 'log-output' => 'none', # Binary logging is often required. But if not required it makes the simplification process # maybe a bit slower and consumes additional storage space. 'log-bin' => undef, 'log_bin_trust_function_creators' => 1, # With log-bin and the default sync-binlog=0 we risk to get 'TBR-1136' (just to be expected # and not a bug) in Crashrecovery tests. 'sync-binlog' => '1', 'loose-debug_assert_on_not_freed_memory' => 0, # Example for InnoDB with encryption # https://mariadb.com/kb/en/library/innodb-encryption/ # ------------------------------------------------------- 'plugin-load-add' => 'file_key_management.so', 'file-key-management-filename' => '$RQG_HOME/conf/mariadb/encryption_keys.txt', # 'loose-innodb-encryption-threads' => 7, # 'loose-plugin-load-add' => 'provider_lzo.so', 'loose-plugin-load-add' => 'provider_bzip2.so', 'loose-plugin-load-add' => 'provider_lzma.so', 'loose-plugin-load-add' => 'provider_snappy.so', 'loose-plugin-load-add' => 'provider_lz4.so', }, }, # grammar_flags #-------------- # You could set "grammar_flags" to GRAMMAR_FLAG_COMPACT_RULES so that rules such as # rule: a | a | a | a | a | a | b ; are compressed to rule: a | b # before simplification. # The impact of that at test runtime is # Known (irrelevant up till big) disadvantage of that at grammar runtime # - non compressed: Generation of 86% 'a' and 14% 'b'. # - compressed: Generation of 50% 'a' and 50% 'b'. # regarding # - likelihood to replay some desired outcome # Jumps to the better are possible too but less likely. # - evolution of resource consumption of tests at runtime. # Jumps to the better are possible too but less likely. # The rqg_batch resource control is good in handling that some more and more bigger fraction # of concurrent tests becomes critical regarding resource consumption. # But meeting some 100% of all concurrent tests are critical from the begin on might # - exceed the capabilities of resource control to avoid disasters # - not exceed the capabilities but cause a too high fraction of to be stopped runs # # Impact on the maximum number of shrink attempts: # The old grammar simplifier tried to remove any single component of the grammar rule # --> in maximum two attempts with the compressed rule # --> in maximum seven attempts with the non compressed rule # So GRAMMAR_FLAG_COMPACT_RULES gave often in sum (advantage+disadvantage) some benefit. # # The current (new) grammar simplifier determines the unique components ('a' and 'b') and tries # than to remove all occurence of some unique component. # --> In maximum two attempts including that the disadvantage described above cannot happen. # # Recommendation: # Do NOT set GRAMMAR_FLAG_COMPACT_RULES. Of course feel free to experiment. # # grammar_flags => +GRAMMAR_FLAG_COMPACT_RULES, # trials #------- # Maximum number of finished RQG runs which did not replay before the simplifier gives up # with that simplification phase or the complete process. # # Phase Give up after a queue of finished and non replaying attempts # PHASE_FIRST_REPLAY $trials and abort the simplifier run # PHASE_THREAD1_REPLAY $trials and switch to the next phase # PHASE_FINAL_REPLAY $trials and report that, give summary and exit # # All other simplification phases work roughly "open end" and do not use the value in $threads # at all. # # Given the fact that certain desired outcomes are often not that likely to reproduce even # if the grammar is capable to do it use a value > 30. trials => 320, # search_var_size #---------------- # Number of bytes (counted from the end of the output file) to be used during # search for expected_output We suck the last "search_var_size" Bytes of the file # to be searched into a variable. # A too huge "search_var_size" could cause problems. # The relevant zone within the file is maybe # - smaller # If our search pattern is unfortunately a bit unspecific and if it # could also occur within irrelevant zones of the file than we might # get false positives. Decreasing "search_var_size" might help. # - bigger # We might get false negatives. Increasing "search_var_size" might # help but I am unsure if any OS and PERL implementation supports # a variable up to that size. search_var_size => 30000000, }