6
0
mirror of https://github.com/FirebirdSQL/firebird-qa.git synced 2025-01-22 13:33:07 +01:00

Reverted MAX_TIME_FOR_WAIT_* settings because some tests failed on fresh snapshots, both Windows and Linux. Removed obsolete parameter.

This commit is contained in:
pavel-zotov 2023-12-12 10:40:55 +03:00
parent e17835387c
commit 5655f4e563

View File

@ -25,11 +25,6 @@ ENCRYPTION_BADKEY = NoSuchkey
[replication]
# Max limit, in seconds, to wait until data that we have added in master
# will appear in replica DB.
#
MAX_TIME_FOR_WAIT_DATA_IN_REPLICA = 35
# Value of 'journal_archive_timeout' parameter for master DB. Default is 10 secons.
#
JOURNAL_ARCHIVE_TIMEOUT = 10
@ -42,24 +37,17 @@ REPLICA_TIMEOUT_FOR_IDLE = 3
#
REPLICA_TIMEOUT_FOR_ERROR = 7
# Max limit, in seconds, to wait until data that we have added in master
# will appear in replica DB.
#
MAX_TIME_FOR_WAIT_DATA_IN_REPLICA = 65
# Max limit, in seconds, to wait until message about replicating segment
# with known number will appear in the replication.log (after we take
# "snapshot" of its original content and compare it with new data):
#
MAX_TIME_FOR_WAIT_SEGMENT_IN_LOG = 35
MAX_TIME_FOR_WAIT_SEGMENT_IN_LOG = 65
# Max limit, in seconds, to wait until message about adding segments to
# processing queue.
# Message looks like thos: 'Added N segment(s) to the processing queue'
# For each such message, we make 'skip -2' lines in log
# and parse timestamp where it occured. This timestamp must be *NEWER*
# then timestamp that we stored before some DDL/DML action for which we want
# to get info about adding segmnets to processing queue.
# Currently this setting is used in
# functional/replication/test_shutdown_during_applying_segments_leads_to_crash.py
#
MAX_TIME_FOR_WAIT_ADDED_TO_QUEUE = 65
# Aliases for main and replica databases as they are defined in the pre-created
# file <QA_root>/qa-databases.conf: