9659 Commits (ee6d4e506ac47a9ef69b60efa5ddfc9cde2cd71d)

 

All Branches   

Search

Author	SHA1	Message	Date
Rene Cannao	ee6d4e506a	ci: retrigger CI after MySQL APT key fix	1 month ago
Rene Cannao	25c8fd1609	test/tap/tests: drain in-flight monitor cycle in pgsql-servers_ssl_params-t ... The test samples PgSQL_Monitor_ssl_connections_OK immediately after LOAD PGSQL SERVERS TO RUNTIME, then sleeps 5s and checks the counter did not advance (TLSv1 pin should have broken SSL). A monitor connect cycle scheduled with the OLD params can land AFTER ok_before is taken but BEFORE the sleep, succeeding and falsely bumping the counter. Poll for two consecutive equal 1s samples so ok_before is recorded after the new config has taken effect and the counter has plateaued.	1 month ago
Rene Cannao	96c686dafa	MySQL_Monitor: GR thread ignores cached ping state on first iteration ... Why: mysql_server_ping_log can carry stale "unpingable" entries from before monitor_GR_thread_HG was (re)started (e.g. a previous test left those hostnames marked bad). With the cache filter applied on the very first cycle, find_resp_srvs() returns empty, the writer HG stays empty for a full healthcheck_interval, and GR-based tests flake on warm-up. Probe all configured hosts on the first iteration so subsequent cycles see a fresh ping_log. The filter resumes from iteration two onward.	1 month ago
Rene Cannao	96bd55784d	test/tap/tests: wire mysql-zstd_compression_level_libmysql-t into tests target ... Commit 174c5bda2 added the pattern rule for the _libmysql variant of the zstd_compression_level test but did not add it to the 'tests:' target list, so 'make build_tap_tests' silently skipped building it. Add the missing entry so the libmysql variant is built alongside its siblings.	1 month ago
Rene Cannao	bce08084b8	test_cluster_sync: wait_for_node_sync must treat "row absent" as not-synced ... wait_for_node_sync() in test_cluster_sync-t.cpp defaults row_value to -1, updates it from the result row only when both myrow and myrow[0] are non-null, then checks: if (row_value == 0) { not_synced = true; ... } This catches "row present but empty" (row_value == 0) but silently misses "row absent" (row_value stays at the -1 default when mysql_fetch_row returns NULL). The common predicate passed through this helper is: SELECT LENGTH(checksum) FROM stats_proxysql_servers_checksums WHERE hostname='%s' AND port='%d' AND name='%s' That row does not exist on a freshly-spawned replica until it has first synchronised checksums with the peer whose hostname/port the test is polling. Under heavy CI load the replica takes longer to reach that point; the loop exits as "synced" before the row exists; the caller's fetch_remote_checksum() then correctly returns empty and aborts the test with "Failed to fetch current checksum for module 'mysql_servers_v2'". That is exactly the failure observed in legacy-g5 / mysql84-g5 / mysql90-g5 during the multi-group CI run. mysql95-g5 passed because it started roughly two hours later, after concurrent groups had finished. Fix: treat row_value <= 0 as not-synced, so the "row absent" case is polled for the full CHECKSUM_SYNC_TIMEOUT instead of being silently skipped. Positive values still mean "synced" and exit the loop immediately, so there is no latency cost in the fast path. Verified: test_cluster_sync-t now passes 399/399 in legacy-g5; the 'wait_for_node_sync' timeouts that now appear in the log are the disabled-sync half of paired enabled/disabled assertions, where the timeout is the expected outcome.	1 month ago
Rene Cannao	2b1a4262b1	tap/utils: add wait_for_log_match() to fix log-scrape races ... check_logs_for_command() in pgsql-copy_from_test-t did a single-shot call to get_matching_lines() right after the SQL that was expected to cause the "Switching to Fast Forward" / "Switching back to Normal" log line. Because ProxySQL writes that line asynchronously with respect to the query's reply, the scan occasionally reached EOF before the producer had flushed the line, turning the assertion into a flake. The failure that originally surfaced this was legacy-g1, test 85/327 of pgsql-copy_from_test-t: 1 of 236 assertions (not ok 126 - "Switching back to Normal mode"). It never reproduced under three targeted reruns, which is consistent with a timing race rather than a logic bug. Two changes: 1. Add wait_for_log_match() in test/tap/tap/utils.{h,cpp}: retry get_matching_lines() up to a timeout, clearing both eofbit and failbit between iterations so successive getline() calls pick up lines appended since the last scan. (Clearing only failbit, as get_matching_lines does internally, is not enough — once a stream has hit EOF its sticky eofbit keeps getline() from reading new bytes.) Defaults: 2000 ms total budget, 100 ms between polls — matching the idiom already used in admin_set_credentials_logging-t. 2. Rewrite check_logs_for_command() in pgsql-copy_from_test-t.cpp to call the new helper. Positive assertions still return as soon as the line appears (no added latency in the common case). Negative assertions (check_logs_for_command(...) == false) now wait up to the full timeout to confirm absence, closing the symmetrical race where a line would have arrived a few hundred ms later than the single-shot scan. Verified: 3/3 reruns of pgsql-copy_from_test-t in legacy-g1 post-fix all pass 236/236, runtime ~40 s per run (single-shot version was slightly faster because it short-circuited on negative assertions without waiting).	1 month ago
Rene Cannao	6322d58376	sqlite3: CACHING_SHA2_PASSWORD() accepts optional rounds arg (closes #5640) ... The ProxySQL admin SQLite3 extension CACHING_SHA2_PASSWORD() previously always emitted hashes with 5000 rounds (hardcoded "\$A\$005\$" prefix and "\$5\$rounds=5000\$" crypt salt). MySQL's caching_sha2_password_digest_rounds is configurable from 5000 to 4095000 in steps of 1000, so a backend that uses any non-default value produces hashes the extension cannot reproduce — breaking the byte-for-byte hash equivalence test in test_sqlite3_pass_exts-t on e.g. the mysql95 backend where rounds=10000. Extend the SQLite function to accept an optional third integer argument carrying the desired rounds value: CACHING_SHA2_PASSWORD(pass) -> random salt, 5000 rounds CACHING_SHA2_PASSWORD(pass, salt) -> given salt, 5000 rounds CACHING_SHA2_PASSWORD(pass, salt, rounds) -> given salt, given rounds rounds is validated: integer, multiple of 1000, in [5000, 4095000] — matching MySQL's caching_sha2_password_digest_rounds bounds. The "\$5\$rounds=<N>\$" salt prefix and "\$A\$<RRR>\$" hash prefix are now built at runtime from the resolved value, with <RRR> emitted as 3-char zero-padded uppercase hex of (rounds/1000) per MySQL's sql/auth/sha2_password.cc::digest_round_separator(). Update test_sqlite3_pass_exts-t to parse the rounds field from the MySQL-generated hash (chars 3..5 of \$A\$<RRR>\$..., base-16, ×1000) and pass it to CACHING_SHA2_PASSWORD() — so the hash-equivalence assertion matches any backend rounds. Update the INV_INPUTS fixture: 3-arg is now valid, so reject 4-arg ("wrong number"), reject 3-arg with non-integer rounds ("Invalid argument type"), reject out-of-range or non-multiple-of-1000 rounds ("Invalid rounds: ..."). Verified against mysql95 backend (rounds=10000): test_sqlite3_pass_exts-t passes 2117/2117, test_auth_methods-t passes 10774/10774 (previously failing with 50+122 not-ok respectively before the base-16 parse fix in MySQL_Protocol.cpp).	1 month ago
Rene Cannao	4e0efd7536	scripts/lint: pass explicit target to bear-wrapped make ... generate-compile-commands.sh wrapped the top-level build with bear -- make -j\$(nproc) with no explicit target, so the inner make resolved its default goal dynamically. Combined with the previous Makefile bug that left lint-generate-cdb as the default goal, invoking `make` with no arguments produced an exponential fork bomb: lint-generate-cdb → this script → bear -- make -jN → lint-generate-cdb → this script → …, with each level forking up to \$(nproc) concurrent sub-makes under Bear's LD_PRELOAD exec intercept. Spawned hundreds of `bear -- make -jN` processes before grinding the system to a halt. The Makefile default-goal fix in 7a1d639a4 closes the trigger, but the script itself should also be robust against a future re-introduction of the same hazard. Pass `build_src` explicitly as the target so the inner make never re-enters lint-generate-cdb regardless of what the default goal happens to be.	1 month ago
Rene Cannao	7a1d639a4b	build: set default goal to build_src, not the first target ... The Makefile had `.DEFAULT: default` intending to make the `default` target (which builds the project) the fallback when `make` is invoked with no arguments. `.DEFAULT` is a different special target — it provides a fallback *recipe* for targets with no rule, and has no effect on default goal selection. GNU make picks the first real target as the default goal unless `.DEFAULT_GOAL` is set. The first real target in this Makefile is `lint-generate-cdb` (line 19), so `make` with no arguments ran `scripts/lint/generate-compile-commands.sh`, which does `bear -- make -j\$(nproc)` — a full rebuild of the project under Bear's compile-intercept wrappers. Each C++ compile under Bear spawned a wrapper process, producing hundreds of bear processes per plain `make` invocation and burying the intended default behaviour. Replace `.DEFAULT: default` with `.DEFAULT_GOAL := default` so `make` with no arguments runs `default: build_src` as originally intended.	1 month ago
Rene Cannao	4e39f3bdc4	fix: parse caching_sha2_password rounds as hex (auth fails on rounds >= 10000) ... MySQL stores the rounds field of caching_sha2_password hashes ($A$<RRR>$<salt><hash>) as 3-char zero-padded uppercase hex of (rounds/1000). See sql/auth/sha2_password.cc: sprintf(rounds_str, "%03X", m_stored_digest_rounds) ProxySQL was parsing this field with stol(s, 10) (default base-10), which silently truncates at the first hex digit (A-F): 005 → 5 (5000 rounds, MySQL 8.0 default) ✓ matches base-16 009 → 9 (9000 rounds) ✓ matches base-16 00A → 0 (10000 rounds, stops at 'A') ✗ should be 10 010 → 10 (16000 rounds, decimal!) ✗ should be 16 01A → 1 (26000 rounds, stops at 'A') ✗ should be 26 The wrong rounds value is then fed into sha256_crypt_r() via "$5$rounds=<n*1000>$<salt>", producing a digest that does not match the stored hash, so verification fails with Access denied. Trigger: any MySQL backend with caching_sha2_password_digest_rounds >= 10000 (or any value whose hex encoding contains A-F). Surfaces in CI on the mysql95 dbdeployer image, where backend-generated hashes start with $A$00A$. The bug is latent on MySQL 8.0/8.4/9.0 with default rounds=5000 because "005" parses identically in base-10 and base-16. Fix: pass base=16 to stol() in both PPHR_verify_sha2() and PPHR_sha2full().	1 month ago
Rene Cannao	ef351a6a67	test/groups: drop reg_test_3992 from mysql8x/95 groups ... The reg_test_3992_fast_forward_malformed_packet-{t,pymysql,mysqlsh} tests hard-code MariaDB-specific users (mariadbuser, mariadbuserff) that are provisioned only by infra-{mariadb10,dbdeployer-mariadb10}. The mysql84-g2, mysql90-g2 and mysql95-g2 groups don't include a MariaDB infra, so the test fails immediately with "Access denied for user 'mariadbuserff'". Restrict the three variants to legacy-g2 and the mysql-* knob-variant g2 groups (which inherit the legacy infra layout including MariaDB).	1 month ago
Rene Cannao	b860662c17	test/infra: slim dbdeployer images (~70-77% smaller) ... Every dbdeployer-* CI image was carrying dead weight from the MySQL/MariaDB unpack step. Cleanup is folded into the same RUN layer as the unpack so the removals actually reclaim space instead of leaving it in a prior layer: - remove the tarball that 'dbdeployer downloads get-unpack' left at / (~1GB) - remove bin/mysqld-debug (debug server binary, unused at runtime) - for MySQL 5.7 only: also remove lib/libmysqld.a and lib/libmysqld-debug.a (embedded-server static libs, deprecated in 5.7 and removed in 8.0) - strip all ELF binaries under bin/ and shared libs under lib/ using binutils installed temporarily and purged within the same layer Result: 2.8 GB -> 653 MB for mysql95, with similar drops across every tier. Existing behavior is preserved (libmysqlclient.a kept, no runtime changes).	1 month ago
René Cannaò	82fadbc1f4	Merge pull request #5623 from sysown/v3.0-issue5621 ... Fix regression: restore upper-word capabilities dropped from greeting	1 month ago
René Cannaò	17a54193cc	Merge pull request #5637 from sysown/v3.0_new_zstd ... feat: add mysql-zstd_compression_level variable	1 month ago
Rene Cannao	4d251c80ec	Revert 'enable_client_session_tracking' variable; keep greeting fix ... Issue #5621 mis-diagnosed "CLIENT_SESSION_TRACKING missing from the greeting" as a long-standing configuration gap and proposed a new 'mysql-enable_client_session_tracking' variable analogous to 'mysql-enable_client_deprecate_eof'. On closer inspection this was in fact a regression introduced by commit 8c6a6444d (zstd refactor), which dropped the hard-coded upper-word bits from the greeting. The right fix is simply to restore those hard-coded bits — commits 536c9d916 and 6b311b701 already do that via the 'extended_capabilities' local in 'generate_pkt_initial_handshake'. The new variable adds no value on top of that: the hard-coded bits cannot be disabled through 'mysql-server_capabilities' (which is OR-combined with the greeting), and there is no protocol hazard motivating a per-instance off-switch for CLIENT_SESSION_TRACKING, unlike CLIENT_DEPRECATE_EOF. Revert the variable (MySQL_Thread.h / proxysql_structs.h / MySQL_Thread.cpp / MySQL_Protocol.cpp) and restore CLIENT_SESSION_TRACKING to the 'extended_capabilities' literal, matching v3.0.6 exactly. Keep the test's doxygen / diag / baseline-check rewrite from the investigation — it's strictly better coverage and will catch any future regression of the hard-coded bits early. Test plan reduced to 2 scenarios (deprecate_eof on/off) since session_tracking is now unconditionally advertised.	1 month ago
Rene Cannao	174c5bda20	test: expand zstd_compression_level test with MySQL 8.4 C API and timing benchmark ... The existing test only verified admin variable behavior (default, range, independence). It did not prove that ZSTD compression was actually active on the wire. Two new test variants address this: MariaDB connector path (mysql-zstd_compression_level-t): - Tests 1-9: unchanged (variable defaults, range validation, independence) - Tests 10-11: use mysql CLI via execvp with --compression-algorithms=zstd and --zstd-compression-level={3,19}. Each call spawns a new process (= new connection). Verifies CONNECTION_ID() retrieval and large resultset transfer. Skipped if mysql CLI lacks zstd support. MySQL 8.4 connector path (mysql-zstd_compression_level_libmysql-t): - Tests 1-9: same as MariaDB path - Test 10: establishes a ZSTD connection using mysql_options( MYSQL_OPT_COMPRESSION_ALGORITHMS, "zstd") and prints mysql_thread_id() without running any query. - Test 11: timing benchmark proving compression is active. Creates a query rule (rule_id=1, cache_ttl=60000) to cache all SELECTs, then runs a 576-row resultset query 1000 times on a plain connection and 1000 times on a ZSTD level 22 connection. ZSTD level 22 is extremely CPU-intensive: observed 40122ms vs 858ms (46.7x ratio). A ratio >= 3x proves compression is really running on the client<->ProxySQL link. Other changes: - MySQL_Protocol.cpp: simplify redundant clamping to a simple cast (the variable is already validated at SET time) - Makefile: add build rule for _libmysql variant linking against MySQL 8.4 connector - groups.json: register _libmysql variant for mysql84/90/95-g1 - CLAUDE.md: update testing section with CI script usage and DO NOT list	1 month ago
Rene Cannao	6b311b7014	Restore greeting upper-word caps via local 'extended_capabilities' ... Previous commit (536c9d916) OR-ed the dropped upper-word bits into 'mysql_thread___server_capabilities', which made them leak into '(*myds)->myconn->options.server_capabilities' — a behaviour delta vs. pre-8c6a6444d. Revert that and reinstate the original pattern: a local 'extended_capabilities' whose only consumer is 'upper_word'. Seed it with the hardcoded baseline (CLIENT_MULTI_*, CLIENT_PLUGIN_AUTH, CLIENT_REMEMBER_OPTIONS) and fold in any other upper-word bits currently set in 'server_capabilities' (CLIENT_DEPRECATE_EOF, CLIENT_SESSION_TRACKING, CLIENT_ZSTD_COMPRESSION, ...) so the greeting stays in sync with the per-session / per-toggle state — preserving 8c6a6444d's zstd advertisement while restoring the #4023 baseline.	1 month ago
Rene Cannao	536c9d9169	Restore greeting upper-word capabilities dropped in 8c6a6444d ... The zstd refactor in 8c6a6444d replaced the per-greeting 'extended_capabilities' local with 'server_capabilities' derived from 'mysql_thread___server_capabilities'. As a side effect, the four upper-word bits the greeting used to hardcode were no longer advertised: CLIENT_MULTI_STATEMENTS CLIENT_MULTI_RESULTS CLIENT_PS_MULTI_RESULTS CLIENT_REMEMBER_OPTIONS OR these bits back into 'mysql_thread___server_capabilities' before the upper-word memcpy, matching what real MySQL 8.x advertises (see #4023). Also rewrite test_greeting_capabilities-t with doxygen documentation and step-by-step diag() tracing that decodes capability bitmasks to names, and reinstate the baseline-capability assertion that silently degraded when commit 6e1483f1f tightened the caps_match overwrite into '&='. In 'PPHR_2', fold the CLIENT_SESSION_TRACKING enforcement into the shared two-step comment block for clarity.	1 month ago
Rene Cannao	f9f6f74ecc	fix: address code review issues in zstd compression level test ... - Remove mysql_error(NULL) UB on failed admin connection (use static error string instead). - Correct Test 10 comment and label: it exercises zlib (CLIENT_COMPRESS), not zstd compression, verifying the new variable doesn't break existing compressed connections.	1 month ago
Rene Cannao	4631b1f466	fix: clean groups.json diff — only add mysql-zstd_compression_level-t entry	1 month ago
Rene Cannao	6dae8d125f	test: add TAP tests and housekeeping for mysql-zstd_compression_level ... - New test mysql-zstd_compression_level-t.cpp: validates default value, range enforcement (1-22), rejection of 0 and 23, independence from mysql-protocol_compression_level, and functional compressed connection. - Register mysql-zstd_compression_level-t in groups.json (same groups as mysql-protocol_compression_level-t). - Add variable visibility check to reg_test_2793-compression-t.cpp. - Add unit test binary pattern to .gitignore.	1 month ago
Rene Cannao	1c3057ecf2	feat: use mysql-zstd_compression_level for zstd compression ... Replace mysql_thread___protocol_compression_level with mysql_thread___zstd_compression_level in both the handshake (MySQL_Protocol.cpp) and data stream (mysql_data_stream.cpp) zstd level selection paths, so the two compression algorithms can be configured independently.	1 month ago
Rene Cannao	aa24529f39	feat: register mysql-zstd_compression_level variable in MySQL thread	1 month ago
Rene Cannao	266a10617f	feat: declare mysql_thread___zstd_compression_level thread-local and struct member	1 month ago
René Cannaò	aecac96c84	Merge pull request #5638 from sysown/fix/lint-groups-json-format ... fix: reformat groups.json and add --fix to linter	1 month ago
Rene Cannao	a0f685b998	fix: reformat groups.json to one-line-per-entry and add --fix to linter ... groups.json was reformatted with multi-line arrays by a recent merge, breaking the one-line-per-test convention documented in README.md. Changes: - Reformat groups.json to canonical format (one line per test, compact arrays, sorted keys, space before colon). - Add --fix mode to lint_groups_json.py that auto-reformats the file in-place, preventing this class of issue in the future.	1 month ago
René Cannaò	13ff9d7671	Merge pull request #5625 from sysown/v3.0-dbdeployer-mysql84-gr ... infra: migrate mysql84-gr to dbdeployer and cap pgsql_servers max_connections	1 month ago
Rene Cannao	7c6f42bcd8	fix: MySQL 9.x charset handling and log_last_insert_id test race ... - validate_charset: compare server_version as a numeric major version instead of testing the first character, so MySQL 9.x and later are treated like 8.x for collations with id >= 255 - test_log_last_insert_id-t: re-enable PROXYSQL FLUSH LOGS; with buffered query logging, eventslog_flush_timeout=0 alone still races the periodic flush thread	1 month ago
Rene Cannao	d212102ce5	fix(tests): drop pgsql-* tests from mysql{84,90,95}-g[1-5] ... Follow-up to 4534e5b4d (merge legacy-g[1-5] into mysql{84,90,95}-g[1-5]). The previous merge was over-inclusive: legacy-g* contains PostgreSQL tests (named 'pgsql-*' or 'pgsql_*' or '*_pgsql_*') that exercise ProxySQL's PostgreSQL front-end against the docker-pgsql16-single backend. Those tests don't care which MySQL version is also present, and the mysql{84,90,95} groups' infras.lst only lists infra-dbdeployer-mysqlXX — no PostgreSQL backend is brought up. So in myrun3 the merged pgsql tests failed (no backend) or hung until the per-group timeout (test_ffto_pgsql_concurrent-t). Removed 153 group memberships (pgsql-containing test names) from mysql{84,90,95}-g[1-5]. Safety check confirmed: no pgsql-containing test was in mysql*-g* before the merge, so this revert is scoped exactly to memberships the merge added. New sizes: legacy mysql84 mysql90 mysql95 g1 87 78 72 78 g2 43 45 45 45 g3 40 40 40 40 g4 94 61 61 61 g5 5 6 6 6 Net result vs pre-merge (pre-4534e5b4d): - mysql84-g1 back to 78 (same as pre-merge) - mysql90-g1 up from 16 to 72 (the non-pgsql legacy tests; +56) - mysql95-g1 back to 78 (same as pre-merge) - g2 / g3 / g5 unchanged from pre-merge for 84/95, mysql90-g* gets a few non-pgsql additions - g4 keeps the non-pgsql portion of the legacy merge (61 vs 60) Legacy-g[1-5] are untouched — pgsql tests remain where they belong. check_groups.py reports 385/385 registered, no orphans.	1 month ago
Rene Cannao	4534e5b4dc	feat(tests): merge legacy-g[1-5] test sets into mysql{84,90,95}-g[1-5] ... Every TAP test in legacy-gN is now also a member of mysql84-gN, mysql90-gN, and mysql95-gN (N=1..5). No tests removed from any group; legacy-g[1-5] keeps its existing membership intact. Rationale: the legacy group covers the MySQL 5.7 / MariaDB 10 / PgSQL / ClickHouse matrix, but many of its TAP tests are not inherently tied to MySQL 5.7 — they exercise ProxySQL behavior that should also hold against modern MySQL backends (8.4, 9.0, 9.5). Running them against those newer servers widens the matrix and catches 9.x-specific regressions in tests that weren't previously in a 9.x group. Mechanical merge via a walk over groups.json: for each test: for N in 1..5: if 'legacy-gN' in memberships: add 'mysql84-gN', 'mysql90-gN', 'mysql95-gN' if absent 224 new memberships added. Per-bucket union size (i.e. now a superset of legacy-gN): g1: legacy=87 mysql84=93 mysql90=87 mysql95=93 g2: legacy=43 mysql84=45 mysql90=45 mysql95=45 g3: legacy=40 mysql84=40 mysql90=40 mysql95=40 g4: legacy=94 mysql84=96 mysql90=96 mysql95=96 g5: legacy=5 mysql84=7 mysql90=7 mysql95=7 Verified as supersets (every test in legacy-gN is present in mysql{84,90,95}-gN). check_groups.py reports 385/385 tests registered, no orphans. Expect new 9.x-specific failures to surface when the mysql{90,95}-g* groups run these newly-inherited legacy tests — they're likely to hit the same family of mysql_native_password / caching_sha2_password issues we've already been working through in the sibling PR threads. Those will be triaged as they appear.	1 month ago
Rene Cannao	d5b796cdea	fix(test/tap): halve expected backend conn count in test_sqlite3_pass_exts-t on 9.x ... Follow-up to cbbd10ba7 (skip native_password backend fixtures on MySQL 9.x). The Phase-3 end-to-end loop runs RAND_USERS_GEN (100) iterations on 8.4 — 50 with mysql_native_password + 50 with caching_sha2_password — and each successful login creates one backend connection. On 9.x the native half is skipped, so only 50 actual connections are made. The post-loop assertion "Number of backend conns created should match conn attempts" was hardcoded to compare against RAND_USERS_GEN. When native was skipped, actual=50 but expected=100, producing: not ok 2113 - Number of backend conns created should match conn attempts exp:'100', act:'50' Fix: compute expected_conns based on g_mysql_supports_native_password (the same flag that gates the Phase-3 loop range) and use it both for the wait_for_cond() condition string and the assertion. Verified on a live mysql90 backend: test now reports ok 2113 - ... exp:'50', act:'50' and exits 0 (2113/2113 assertions pass in 3.4s).	1 month ago
Rene Cannao	cbbd10ba74	fix(test/tap): skip native_password backend fixtures on MySQL 9.x in test_sqlite3_pass_exts-t ... Fixes #5631. The test has three logical phases: Phase 1 Admin SQLite3 extension validation for MYSQL_NATIVE_PASSWORD() and CACHING_SHA2_PASSWORD() — pure hash computation inside ProxySQL, does not touch the backend. Phase 2 MySQL/Admin hash compatibility — creates USER_GEN_COUNT (100) users on the backend, half with mysql_native_password and half with caching_sha2_password, then compares the backend's authentication_string with the hash that ProxySQL's Admin SQLite3 function produces. Phase 3 End-to-end connection test — creates RAND_USERS_GEN (100) users with the same 50/50 split and attempts to connect through ProxySQL. On MySQL 9.0+ the mysql_native_password plugin is not loadable, so the first CREATE USER IDENTIFIED WITH 'mysql_native_password' in Phase 2 fails with ER_PLUGIN_IS_NOT_LOADED and the test bails after only 10 assertions (all of Phase 1 passes — ProxySQL's internal hash extensions work fine on 9.x; this was a good green signal). Fix: - Add g_mysql_supports_native_password; set to false on server_version >= 9.0. - Adjust actual_test_count so plan() matches reality: if (has_native) { count += USER_GEN_COUNT + RAND_USERS_GEN; } else { count += USER_GEN_COUNT / 2 + RAND_USERS_GEN / 2; } - Wrap the Phase 2 native_password loop in 'if (has_native)'. - Phase 3 uses 'for (i = 0 .. RAND_USERS_GEN)' with 'i < 50 ? native : sha2'. Skip the native half by starting the loop at RAND_USERS_GEN/2 when has_native is false. Phase 1 coverage is fully preserved — the ProxySQL Admin SQLite3 hash functions (including MYSQL_NATIVE_PASSWORD()) still work on 9.x; only the backend-side CREATE USER path is skipped.	1 month ago
Rene Cannao	5bb19a99b1	fix(test/tap): skip reg_test_4935-caching_sha2-t on MySQL 9.x ... Fixes #5629. This regression test for issue #4935 ("proxysql ignores database in DSN at first login") uses a hardcoded plan(864) built around a 2×2 fixture table (2 mysql_native_password users + 2 caching_sha2_password users) crossed with 2 def_auths × 3 req_auths × 2×2×2 bool matrices. On MySQL 9.0+ the mysql_native_password plugin is unavailable and any CREATE USER IDENTIFIED WITH 'mysql_native_password' hits ER_PLUGIN_IS_NOT_LOADED, killing the test during fixture setup. Filtering the fixture matrix in-place to remove the native half would require re-deriving plan(N) from scratch — the current plan(864) encodes the expected-pass count of a non-trivial loop that has a per-iteration 'exp_first_login_failure()' skip. Getting that math right and keeping it right under future changes is fragile. Pragmatic fix: detect 9.x and skip the whole test with plan(0). The #4935 regression (database-in-DSN on first login for caching_sha2) is already fully exercised against the mysql57 and mysql84 infras in legacy-g* / mysql84-g*. Losing the 9.x-specific coverage for this one regression test is an acceptable trade-off — the ProxySQL code path under test is server-version-agnostic, so additional 9.x coverage adds little beyond what 8.4 already provides. Mirrors the skip pattern the test suite already uses for MySQL < 8.0.	1 month ago
Rene Cannao	5f50724845	fix(test/tap): skip mysql_native_password fixtures on MySQL 9.x in test_auth_methods-t ... Fixes #5626. The test's fixture table (backend_users) has 18 users split 9/9 across mysql_native_password and caching_sha2_password. On MySQL 9.0+ the native-password plugin is unavailable, and the test bailed on creating the first native-password fixture (dualpass2). Following the existing version-gating pattern in the same test (which already branches on server_version < 80000 for MySQL 5.x and on is_mariadb for MariaDB), add a third branch: has_native_password = true if server_version >= 90000 && !is_mariadb: has_native_password = false Then thread has_native_password through: - the backend_users fixture list (filter out native entries before passing to config_mysql_backend_users) - def_auths (the "ProxySQL default authentication plugin" matrix) - req_auths (the "client-requested authentication plugin" matrix) plan() adjusts automatically because the plan count is computed from scs_stats/rnd_scs_stats which are derived from the actual created users and config_combs, not hardcoded. Coverage on 5.7 and 8.4 is unchanged: both plugins still exercised. On 9.x, only the caching_sha2_password half runs — which is the only half the backend can support anyway.	1 month ago
Rene Cannao	8c36be3606	fix(test/tap): make create_mysql_user helper backend-version aware ... Fixes #5627, #5628, #5630. The shared test helper test/tap/tap/utils.cpp:create_mysql_user() was hardcoding IDENTIFIED WITH 'mysql_native_password' in its CREATE USER template. MySQL 9.0 removed that plugin entirely (the .so in the tarball is a client-lib stub only; INSTALL PLUGIN fails with "Can't find symbol '_mysql_plugin_interface_version_'"), so CREATE USER IDENTIFIED WITH 'mysql_native_password' returns ER_PLUGIN_IS_NOT_LOADED on 9.x backends. Tests that use this helper as setup — they don't care which auth plugin the backend uses, they just need a working user — were failing before executing a single assertion. Affected tests (all in mysql90-g* / mysql95-g*): test_com_reset_connection_com_change_user-t (#5627) test_default_value_transaction_isolation_attr-t (#5628) test_server_sess_status-t (#5630) Fix: select the IDENTIFIED clause at runtime based on mysql_get_server_version(): - server < 9.0 → keep the explicit 'mysql_native_password' clause (preserves behavior on 5.7 / 8.4 for any callers that implicitly depend on a native-password backend user) - server >= 9.0 → use IDENTIFIED BY (server default plugin, which is caching_sha2_password on 9.x) Auth-sensitive tests that specifically exercise plugin-iteration (e.g. test_auth_methods-t, reg_test_4935-caching_sha2-t) do not use this helper — they use create_mysql_user_exp_creds() in utils_auth.h, which takes an explicit plugin argument. Those are handled in separate commits.	1 month ago
Rene Cannao	e11411fde2	fix(infra): use 'mysql -E -e STATEMENT' instead of 'mysql -e STATEMENT\G' ... MySQL 9.5.0 client (no longer?) accepts '\G' as a statement terminator when the statement is passed via '-e': $ mysql -e 'SHOW REPLICA STATUS\G' ERROR at line 1: Unknown command '\G'. '\G' still works interactively, and still works in -e on 8.4 and 9.0.1. This is a silent behavior change in the 9.5 client binary. (The 9.0.1 client in the same tarball tree handles '\G' fine.) docker-mysql-post.bash uses this to query replication status after container startup. Under 9.5, the mysql command exits non-zero, the captured output is empty, the subsequent grep in a pipeline returns 1, and set -e + pipefail kill docker-mysql-post.bash. That in turn kills docker-compose-init.bash which kills ensure-infras.bash. Net effect: every mysql95 / mysql95-binlog group fails before running a single test, logging just: Verifying MySQL on ...:3308... OK Checking replication on port 3307... (stops here) Fix: switch from '-e "SHOW REPLICA STATUS\G"' to '-E -e "SHOW REPLICA STATUS"'. '-E' (a.k.a. --vertical) has been supported by mysql(1) since 3.x, works identically on MariaDB 10, MySQL 5.7 / 8.4 / 9.0 / 9.5. The grep/awk that extracts Replica_IO_Running and Replica_SQL_Running keeps working unchanged since the vertical output format is the same. Applied to all 10 docker-mysql-post.bash files under test/infra/infra-dbdeployer-*. No change needed to the ci-infra Docker images — docker-mysql-post.bash runs on the host after the container starts.	1 month ago
Rene Cannao	bee37b2cb8	fix(tester): abort when TAP_GROUP is set but has no tests registered ... Previously, if TAP_GROUP was set but the group had no entries in test/tap/groups/groups.json (typo, missing registration, etc.), the tester logged a warning and silently fell back to running ALL 325 TAP tests. In a multi-group parallel run this turns a misconfiguration into a multi-hour hang that only surfaces when the per-group TIMEOUT fires. We hit this in practice: mysql90-g[2-5] existed as launch targets in the runner but hadn't been populated in groups.json yet. The tester fell back to the full suite, and the groups TIMED OUT after chewing through pgsql tests they had no business running. Change behavior to log at CRITICAL and sys.exit(1) in two cases: 1. TAP_GROUP is set, groups.json is present, but the group has no tests registered. 2. TAP_GROUP is set and groups.json is missing entirely. The "no TAP_GROUP specified" path is unchanged — that's the legitimate way to run the full suite directly (outside the group runner). Error messages explicitly tell the operator what to do: either register tests for the group, or unset TAP_GROUP to run the full suite intentionally.	1 month ago
Rene Cannao	7eee687415	feat(tests): mirror mysql84-g[2-5] test sets into mysql90-g[2-5] ... Populates mysql90-g2 through mysql90-g5 with the same test assignments as mysql84-g2..5, matching the structure already applied to mysql95. Adds 147 group memberships, all targeting existing tests. mysql84-g2: 42 → mysql90-g2: 42 mysql84-g3: 40 → mysql90-g3: 40 mysql84-g4: 60 → mysql90-g4: 60 mysql84-g5: 5 → mysql90-g5: 5 mysql90-g1 intentionally left as the existing 16-test shared subset (still matches mysql91-g1 / mysql92-g1 / mysql93-g1). If you want g1 expanded to mysql84-g1 parity later (78 tests), it's a one-line follow-up. Fixes the runaway "TIMEOUT" seen in multi-group runs that included mysql90-g[2-5]: the tester would previously fall back to running all 325 tests when a group had no members (see separate commit that eliminates that fallback). check_groups.py still reports 385/385 registered, no orphans.	1 month ago
Rene Cannao	efa7922d01	feat(infra): add dbdeployer-based MySQL 9.0/9.5 binlog-reader infras ... Mirrors the existing infra-dbdeployer-mysql84-binlog layout (3-node replication + proxysql_binlog_reader on GTID ports 6020/6021/6022) for MySQL 9.0 and 9.5. Group replication binlog variant not requested; skipped. New infrastructures: test/infra/infra-dbdeployer-mysql{90,95}-binlog/ Hostgroup PREFIX assignment: mysql90-binlog PREFIX=37 (WHG/RHG/BHG/OHG = 3700/3701/3702/3703) mysql95-binlog PREFIX=38 (3800/3801/3802/3803) MySQL tarballs (x86_64 glibc2.17 variants, same as the standalone 9.x infras): mysql-9.0.1-linux-glibc2.17-x86_64.tar.xz mysql-9.5.0-linux-glibc2.17-x86_64.tar.xz Dropped the `-c mysql_native_password=ON` dbdeployer flag and the `IDENTIFIED WITH 'mysql_native_password'` clause, same as the other 9.x infras, since the plugin isn't usable on MySQL 9.x servers. Group wiring (test/tap/groups/): mysql{90,95}-binlog/ — env.sh + infras.lst, mirroring mysql84-binlog/ groups.json: registered mysql90-binlog-g[12] and mysql95-binlog-g[12] mirroring mysql84-binlog-g[12] exactly (g1=3 tests, g2=1 test). check_groups.py reports 385/385 registered. KNOWN LIMITATION — proxysql_binlog_reader v2.3 cannot authenticate: Smoke test of mysql90-binlog confirmed 3-node replication deploys cleanly and users replicate, but the binlog reader processes fail to start with: Could not mysql_real_connect(): Authentication plugin 'caching_sha2_password' reported error: Authentication requires secure connection. : 2061 Root cause: the bundled proxysql_binlog_reader v2.3 supports only -h/-u/-p/-P/-l/-L options — no SSL, no --get-server-public-key. MySQL 9.x's default caching_sha2_password requires either SSL or a preconfigured RSA public key, neither of which the reader can provide. mysql_native_password isn't a workable escape hatch on 9.x either: the .so still ships in the tarball but `INSTALL PLUGIN` fails with "Can't find symbol '_mysql_plugin_interface_version_'" — it's kept as a client library stub only. Resolution requires either (a) a newer proxysql_binlog_reader that speaks caching_sha2_password or supports SSL, or (b) SSL wrapping at the container level. Neither change is part of this commit; flagging here so the limitation is visible when the tests start failing under mysql{90,95}-binlog-g[12]. MySQL 8.4 binlog flow is unaffected.	1 month ago
Rene Cannao	f07859fd40	feat(tests): mirror mysql84-g[1-5] test sets into mysql95-g[1-5] ... Every TAP test currently executed against mysql84-g[1-5] is now also executed against the corresponding mysql95-g[1-5] group. Same 5-bucket split, same assignment per bucket: mysql84-g1: 78 → mysql95-g1: 78 mysql84-g2: 42 → mysql95-g2: 42 mysql84-g3: 40 → mysql95-g3: 40 mysql84-g4: 60 → mysql95-g4: 60 mysql84-g5: 5 → mysql95-g5: 5 total: 225 total: 225 Rationale: validates the full 8.4 test surface on MySQL 9.5, which is the whole point of adding the 9.x infras — different MySQL major versions catch different regressions (e.g., mysql_native_password removal in 9.0). Group Replication variants (mysql*-gr-g*) are intentionally out of scope for now. Scripted via a simple walk over groups.json: for each entry containing mysql84-gN, add mysql95-gN if missing, then re-sort. Verified: - 209 new memberships added (225 target - 16 already existing from the earlier mysql95-g1 seeding) - check_groups.py reports 385/385 tests registered, no orphans - per-bucket counts now match mysql84-g[1-5] exactly	1 month ago
Rene Cannao	360d425900	fix(infra): use actual mysql-9.x-linux-glibc2.17-x86_64 tarball names ... My earlier guess was wrong — I hadn't verified against dbdeployer's actual remote catalog. The real x86_64 bundles use glibc2.17 (glibc2.28 is only shipped for aarch64). Confirmed via: dbdeployer downloads list | grep mysql-9.[035] ... mysql-9.0.1-linux-glibc2.17-x86_64.tar.xz mysql-9.3.0-linux-glibc2.17-x86_64.tar.xz mysql-9.5.0-linux-glibc2.17-x86_64.tar.xz Smoke-tested both mysql90 and mysql90-gr images end-to-end: - docker build succeeds - entrypoint completes (3-node replication deployed, GR members all ONLINE) - testuser authenticates successfully on all three ports via caching_sha2_password (default plugin, since we dropped mysql_native_password in the previous commit) - GR user replication propagates to all secondaries	1 month ago
Rene Cannao	de9e73cb5f	feat(infra): add dbdeployer-based MySQL 9.0/9.3/9.5 standalone and GR infras ... Mirrors the existing mysql84 / mysql84-gr layout (single-container dbdeployer sandboxes) for MySQL 9.0, 9.3, and 9.5 — both standalone replication and Group Replication variants. New infrastructures: test/infra/infra-dbdeployer-mysql{90,93,95}/ — standalone replication (3 nodes) test/infra/infra-dbdeployer-mysql{90,93,95}-gr/ — Group Replication (3 nodes, single-primary) Hostgroup PREFIX assignment (continuing the existing convention): mysql90 PREFIX=31 (WHG/RHG/BHG/OHG = 3100/3101/3102/3103) mysql93 PREFIX=32 (3200/3201/3202/3203) mysql95 PREFIX=33 (3300/3301/3302/3303) mysql90-gr PREFIX=34 (3400/3401/3402/3403) mysql93-gr PREFIX=35 (3500/3501/3502/3503) mysql95-gr PREFIX=36 (3600/3601/3602/3603) MySQL 9.x tarballs (via dbdeployer downloads get-unpack) use glibc2.28 (9.x no longer ships glibc2.17 bundles): mysql-9.0.1-linux-glibc2.28-x86_64.tar.xz mysql-9.3.0-linux-glibc2.28-x86_64.tar.xz mysql-9.5.0-linux-glibc2.28-x86_64.tar.xz MySQL 9.x compatibility notes: - mysql_native_password was removed in MySQL 9.0. Dropped both the -c mysql_native_password=ON dbdeployer flag and the IDENTIFIED WITH 'mysql_native_password' clause from CREATE USER / ALTER USER; users now use the server default (caching_sha2_password). ProxySQL may need SSL to authenticate to 9.x backends because caching_sha2_password requires either SSL or a preconfigured RSA key. This is left to follow-up tuning — flagging here for visibility. Group wiring (test/tap/groups/): mysql{90,93,95}/ — env.sh + infras.lst + setup-infras.bash + pre-proxysql.bash (no-op) mirror mysql84/ exactly, only the infra/group names differ mysql{90,93,95}-gr/ — env.sh + infras.lst + pre-proxysql.bash mirror mysql84-gr/; pre-proxysql.bash uses docker exec to configure ProxySQL with GR fallback HGs + users + rules groups.json: registered mysql95-g1 and mysql95-gr-g1 (16 tests each), identical test sets to the existing mysql93-g1 / mysql93-gr-g1 entries. check_groups.py reports 385/385 tests registered, no orphans. No changes touching existing infras; only new files + groups.json append. Validated with `python3 test/tap/groups/check_groups.py`.	1 month ago
Rene Cannao	5c3bc7dee2	fix(infra): cap pgsql_servers max_connections to 50 per HG ... ProxySQL was configured with pgsql_servers.max_connections=500 on BOTH hostgroups (0 and 1) pointing at the same backend, implying a pool cap of 1000 connections against a PostgreSQL container that only allows 120 (117 non-super). Under test workload the non-super slots would fill up and PostgreSQL rejected new Monitor connects with: FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute This caused pgsql-monitor_ssl_connections_test-t (PHASE 1) and pgsql-servers_ssl_params-t (test 33) to fail — the SSL Monitor counter couldn't advance because the Monitor couldn't connect. PostgreSQL doesn't scale well with connection count, so lower the per-hostgroup cap to 50 (total 100 across the two HGs), leaving ample headroom under PG's max_connections=120 for monitor + superuser slots. The 500 value was templated from the MySQL/MariaDB infras during unify-PR-5433-5442, where each backend's server-side max_connections=500 matches ProxySQL's cap. PostgreSQL here is a different beast and the copy-paste didn't fit.	1 month ago
Rene Cannao	1320e7dbe6	feat(infra): add infra-dbdeployer-mysql84-gr and update mysql84-gr group ... New single-container MySQL 8.4 Group Replication infra using dbdeployer with --topology=group --single-primary. Replaces the non-existent infra-mysql84-gr with a working dbdeployer-based setup. Changes: - infra-dbdeployer-mysql84-gr: Dockerfile, entrypoint (GR topology), docker-compose, init/destroy, post scripts, ProxySQL config with mysql_group_replication_hostgroups - mysql84-gr/env.sh: set DEFAULT_MYSQL_INFRA - mysql84-gr/infras.lst: point to infra-dbdeployer-mysql84-gr - mysql84-gr/pre-proxysql.bash: rewritten to use proxysql hostname (not 127.0.0.1), dbdeployer1 servers (not mysql1/2/3), and let the framework handle infra startup GR-specific: SQL_LOG_BIN stays enabled so user creation replicates to all nodes. Monitor user has SELECT on sys.* and performance_schema.* for GR health checks.	1 month ago
Rene Cannao	7c7dee4b66	feat(infra): add infra-dbdeployer-mysql84-gr for Group Replication ... Single-container MySQL 8.4.8 Group Replication infra using dbdeployer with --topology=group --single-primary. One container runs 3 mysqld nodes in a single-primary GR cluster on ports 3306/3307/3308. Key differences from master-slave: - GR topology with automatic failover - mysql_group_replication_hostgroups (4 hostgroups: writer/backup_writer/reader/offline) - Monitor user has SELECT on sys.* and performance_schema.* for GR health checks - PREFIX=30, WHG=3000, RHG=3001, BHG=3002, OHG=3003	1 month ago
René Cannaò	824588d198	Merge pull request #5606 from sysown/lint-tap-tests-static-analysis ... WIP: TAP test linting and partial cleanup	1 month ago
Rene Cannao	13a43e2ffe	fix(test/tap): revert two semantic regressions from cleanup commits ... Two recent "cleanup" commits on this branch silently changed test behavior and caused the tests to fail under myrun2. 1) kill_connection2-t.cpp (regressed in 3f0cd6a0c): The "cleanup - replace NULL with nullptr, convert loops to range-based" commit flipped one assertion from ok(rc == 0, ...) to ok(rc != 0, ...) on the first DO 1 batch after a 12s sleep. With mysql-max_transaction_time=17000 (17s), the connection is still alive at 12s by design — ProxySQL only kills it at ~18s. The original test correctly expected rc == 0 there; the second DO 1 batch (after +12s = 24s total) continues to correctly expect rc != 0. 2) max_connections_ff-t.cpp (regressed in da655099e): The "static analysis narrowing conversions" commit introduced an integer overflow by wrapping a chrono::nanoseconds count in static_cast<int>(). For the 8000ms test the elapsed time is ~8e9 ns, which overflows int32 (max ~2.147e9) and wraps negative, producing "Waited: -0.589502" and a failed assertion. The 2000ms test happened to fit under 2.147e9 ns and kept passing, hiding the bug. Use static_cast<double> for the nanoseconds count, and drop the unnecessary int casts on connect_timeout / poll_timeout — those are already long, so long / 1000.0 is a valid double.	1 month ago
Rene Cannao	3babaada88	fix: remove stale gtid_utils_unit-t from groups.json ... This test was removed in 06b6343dc and replaced by gtid_set_unit-t and gtid_trxid_interval_unit-t. The merge with v3.0 accidentally restored the old entry.	1 month ago
Rene Cannao	2b89708e5f	fix: treat missing test executables as errors in check_groups.py ... Previously tests listed in groups.json but not found on disk were only printed as notes. Now they cause a non-zero exit code.	1 month ago
Rene Cannao	6f5cf1f169	fix: sort groups.json keys after v3.0 merge	1 month ago