19 Commits (6d8dff293973edd1be9cc67be03aac400e85cb4c)

Author	SHA1	Message	Date
Rene Cannao	4bd2f95e5b	fix(pgsql-monitor): add proxy_debug logging and clean up test variable ... - Add proxy_debug(PROXY_DEBUG_MONITOR, 5) calls when clamping fires, so the fix is observable in debug logs. Follows existing pattern from nearby scheduling debug output. - Rename original_monitor_username to monitor_username and clarify it is for diagnostic logging only, since the variable is no longer used for restore after the credential change was removed.	1 month ago
Rene Cannao	30be016be5	fix(pgsql-monitor): clamp next_*_at on LOAD PGSQL VARIABLES TO RUNTIME ... Closes the pgsql-servers_ssl_params-t portion of sysown/proxysql#5610. This is the final of four tests from the flake tracking issue. ## Problem 1 — the scheduler caching bug (lib/PgSQL_Monitor.cpp) `pgsql-servers_ssl_params-t` subtests 32 ("Monitor SSL counter increased with use_ssl=1 and no per-server row") and 34 ("Monitor per-server: SSL OK counter resumes advancing after removing the per-server row") were failing deterministically on v3.0. Both expected `PgSQL_Monitor_ssl_connections_OK` to increase within a few seconds of: SET pgsql-monitor_connect_interval=2000; LOAD PGSQL VARIABLES TO RUNTIME; UPDATE pgsql_servers SET use_ssl=1; LOAD PGSQL SERVERS TO RUNTIME; but the counter stayed at 0. Root cause is state caching in the pgsql monitor scheduler loop (`PgSQL_monitor_scheduler_thread()`): T=0 proxysql starts with default pgsql-monitor_connect_interval =120000. The first scheduler tick schedules an initial connect check; compute_next_intvs() sets next_connect_at = T + 120000 ms = T + 120 seconds. T+<30s> test does SET connect_interval=2000 + LOAD PGSQL VARIABLES TO RUNTIME. fetch_updated_conf() starts returning the new 2000 value, but next_connect_at still points at T+120000 because compute_next_intvs() only updates next_<type>_at when the corresponding task type has fired. T+<35s> test reads ssl_connections_OK at the end of its 5-second wait. Counter still 0 because the next scheduled connect check is ~85 seconds in the future. The scheduler is working correctly; what's missing is a bridge between "runtime variables were just refreshed" and "next_<type>_at should reflect the refreshed (shorter) intervals". Fix: in the scheduler loop, track whether the variable version bumped this iteration, and if so, clamp each next_<type>_at down to cur_intv_start + new_interval whenever the refreshed interval would schedule the next check sooner than the currently-cached value. The clamp is one-way (we never push next_<type>_at FURTHER into the future, because growing the interval should not delay an already- imminent check), idempotent, and safe against interval=0 (disabled) which is left to compute_next_intvs() to set to ULONG_MAX. Applied to all four monitor task types: ping, connect, readonly, repl_lag. Same class of bug affected all of them; fixing only connect would leave analogous latent issues for any test that changes the other intervals at runtime. Verified with the raw experiment before committing: configure monitor/monitor + interval=2000 + use_ssl=1 + LOAD, observe counter ticking at the 2-second cadence within 1-2 seconds of LOAD. Before fix: counter stuck at 0 for ~2 minutes (until the cached 120 s interval naturally elapses). ## Problem 2 — test's hardcoded wrong credentials (pgsql-servers_ssl_params-t.cpp) With the scheduler fix alone, the test was still failing because its main() was doing: SET pgsql-monitor_username='postgres'; SET pgsql-monitor_password='postgres'; on the assumption that the backend had a postgres user with password "postgres". But the actual test infra (test/infra/docker-pgsql16-single) RANDOMIZES `POSTGRES_PASSWORD` on every container startup — e.g. `POSTGRES_PASSWORD=05e792e51d`. Hardcoded 'postgres' never matched, so every monitor connect failed with: FATAL: password authentication failed for user "postgres" which increments connect_check_ERR instead of ssl_connections_OK. After the scheduler fix, these auth failures fired every 2 seconds instead of every 120 seconds — but they were still failures, so the counter never advanced. Fix: remove the username/password switch entirely. The default monitor/monitor user is already configured in the infra's pg_hba.conf and authenticates successfully (I verified this manually via `docker exec psql 'host=... user=monitor password=monitor sslmode=require'` from both inside and outside the proxysql container). The corresponding "restore original values" block is also removed since there's nothing to restore. ## Local verification 3 consecutive runs of the full pgsql-servers_ssl_params-t test in legacy-g4 infra with the patched proxysql + patched test binary: attempt 1: PASS attempt 2: PASS attempt 3: PASS === pgsql-servers_ssl_params-t: 3/3 pass === Subtest-level confirmation from the final attempt's TAP log: # Original monitor: user=monitor interval=120000 ms # Initial PgSQL_Monitor_ssl_connections_OK: 33 # After PgSQL_Monitor_ssl_connections_OK: 36 <- +3 in 5 s ok 32 - Monitor SSL counter increased with use_ssl=1 and no per-server row # With TLSv1 per-server pin, ssl OK before wait: 39 # With TLSv1 per-server pin, ssl OK after wait: 39 (delta=0) ok 33 - Monitor per-server: SSL OK counter does NOT advance when per-server row pins ssl_protocol_version_range to TLSv1 # After cleanup, ssl OK recovered from 41 to 44 <- +3 in 5 s ok 34 - Monitor per-server: SSL OK counter resumes advancing after removing the per-server row All three monitor-SSL subtests now exercise the real code path (SSL handshake happening, counter incrementing, per-server pin blocking SSL as designed) instead of observing a no-op. ## Side effect on pgsql-ssl_keylog-t subtest 7 Subtest 7 of pgsql-ssl_keylog-t was marked as SKIP in PR #5612 because it tripped on the same "pgsql monitor isn't making SSL connections" symptom. With this fix merged, the skip's runtime condition (`lines_before_monitor == lines_after_monitor`) will evaluate to false once the monitor is actually producing SSL handshakes, and the test will fall into the `ok(...)` branch automatically. No separate change to that test is needed — the skip was defensive and is dead code after this fix. ## Why mysql monitor is not touched here This fix is scoped to the pgsql monitor scheduler only. The mysql monitor is a different file (lib/MySQL_Monitor.cpp) with a different scheduling architecture (per-thread timers, not a centralized scheduler). If the same class of bug exists there, it would need a separate patch - out of scope for this PR.	1 month ago
Rahim Kanji	e68f8bb74a	refactor: simplify pgsql_servers_ssl_params schema and pre-parse TLS range ... - Drop ssl_capath and ssl_cipher columns (no libpq equivalents) - Pre-parse ssl_protocol_version_range into ssl_min/max_protocol_version at construction time instead of on every backend connection - Fix Servers_SslParams 3-arg delegating constructor - Update tests, docs, and all consumers (Connection, Monitor, Kill, Admin)	2 months ago
Rahim Kanji	93d0ddf477	fix: add pgsql_servers_ssl_params to tablenames vector and fix monitor fallback ... - Add pgsql_servers_ssl_params to pgsql_servers_tablenames so SAVE/LOAD PGSQL SERVERS TO/FROM DISK correctly persists and restores SSL params. - Fix monitor SSL fallback to use per-server params directly (empty fields omitted) instead of per-field fallback to globals, matching the backend connection behavior.	2 months ago
Rahim Kanji	fec7c12a35	feat: apply per-server SSL params in PgSQL monitor connections	2 months ago
Rene Cannao	ff1398ead5	fix: plumb real hostgroup_id for pgsql replication lag monitoring ... - Add hostgroup_id to mon_srv_t and ext_srvs.\n- Update fetch_updated_conf queries to return hostgroup_id.\n- Use real hostgroup_id in replication_lag_action call.	3 months ago
Rene Cannao	c4fc60bdb0	fix: address security and logic issues in PostgreSQL replication lag monitoring ... - Fix SQL injection in pt-heartbeat query concatenation.\n- Fix copy-paste errors between mysql_thread_ and pgsql_thread_ variables.\n- Restore monitor_replication_lag_group_by_host logic.	3 months ago
Javier Jaramago Fernández	ba5af979ff	feat-wip: Add replication lag support for PostgreSQL monitoring	3 months ago
Rene Cannao	3e37337877	Use RAII for sqlite3 statements across codebase ... - Convert prepare_v2() calls to use unique_ptr RAII pattern - Remove manual sqlite3_finalize calls (now handled by RAII) - Update flush_*_variables functions to use new prepare_v2 return pattern - Apply changes to Admin, Cluster, Monitor, Catalog, and other modules	3 months ago
Rene Cannao	6f415dfdb2	fix: correct RAII migration issues - variable naming and redundant declarations ... - Fixed SAFE_SQLITE3_STEP2 macro errors: renamed 'rc1' to 'rc' in PgSQL_Monitor.cpp functions (update_connect_table, update_ping_table, update_readonly_table, maint_monitor_table) to match the macro's expected variable name - Removed redundant NULL declarations in ProxySQL_Admin_Stats.cpp functions (stats___pgsql_processlist, stats___pgsql_free_connections, stats___pgsql_errors, stats___save_pgsql_query_digest_to_sqlite) - Completed migration of stats___pgsql_errors and stats___save_pgsql_query_digest_to_sqlite to RAII pattern	3 months ago
Rene Cannao	e4704c5a51	refactor: migrate prepare_v2 SIMPLE cases in PgSQL_Monitor.cpp ... Migrated 5 prepare_v2 calls to RAII-based pattern in: - update_monitor_pgsql_servers(): 2 statements (stmt1, stmt32) - update_connect_table(): 1 statement (stmt) - update_ping_table(): 1 statement (stmt) - update_readonly_table(): 1 statement (stmt) - maint_monitor_table(): 1 statement (stmt) Note: Functions shunn_non_resp_srv() and update_srv_latency() were NOT migrated because they use global thread_local cached statements, which is a valid use case for the old API. The RAII pattern ensures automatic cleanup and eliminates manual sqlite_finalize_statement() calls.	4 months ago
René Cannaò	a360dc22ae	Merge pull request #5308 from sysown/v3.0_mac ... Support for ProxySQL compilation on macOS (Darwin/Apple Silicon)	4 months ago
Rene Cannao	2dfd61a958	Replace remaining direct sqlite3_* calls with proxy_sqlite3_* equivalents (address code-review)	4 months ago
René Cannaò	d43ae6e121	Surgical fixes for macOS compatibility: headers, types, and Makefile linking	4 months ago
Rahim Kanji	fae283cf7e	Add SSL and non-SSL connection OK metrics for PostgreSQL monitor connections ... Adds two new metrics, ssl_connections_OK and non_ssl_connections_OK, to improve visibility into PostgreSQL monitor connection status.	6 months ago
Rahim Kanji	7205f424a2	Add SSL support for backend connections in PGSQL monitor	6 months ago
Javier Jaramago Fernández	100630fba5	Second iteration on PostgreSQL monitoring POC ... This commit packs multiple fixes/improvements: - Added READONLY support for PostgreSQL. - Major rework for queries and statements used on monitoring checks: + Checks/Actions rewrote for single instance checks. + Reuse of prepared statements instance of re-preparation. - Fixed missing error handling in connection creation state machine. - Fixed connection rotation in connection pool (now FIFO). - Added support for configurable batching in scheduler thread, via '*_interval_window' variables. These variables allows to define the burstiness of the scheduling within the processing interval. - Added new config variable 'pgsql-monitor_dbname'. Allows to control which 'db' will be target by monitoring connections. - Several fixes for 'poll' timeout computation for worker threads. - Fixed edge cases for current interval detection. - Reduced deviation in scheduling intervals computation. - Refactored and simplified connection event handling. - Improved error messages for monitoring actions. - Replaced several invalid uses of 'mysql_thread___monitor_*' in favor or new 'mysql_thread___monitor_*' variables. - Honor '-M' argument for disabling monitoring support.	2 years ago
Javier Jaramago Fernández	1ebe70bd9e	Cleanup: Fix RELEASE build and removed non-used variable	2 years ago
Javier Jaramago Fernández	705f50e0f9	Add initial POC for PostgreSQL monitoring support	2 years ago