25 Commits (97eab1bbf0ce3c7c453e8a8bb96b2bd564e4758f)

Author	SHA1	Message	Date
Rene Cannao	6f63499731	chore(sonar): silence cpp:S2245 PRNG false-positives in DNS jitter sites ... Two SonarCloud "weak-cryptography" hotspots flagged uses of mt19937 (DNS_Cache.cpp:117) and rand() (PgSQL_Monitor.cpp:2956). Both are non-cryptographic jitter sources -- one to spread the DNS cache TTL refresh, the other to spread the DNS bookkeeping refresh interval -- with no security boundary touching them. Adding inline NOSONAR annotations with the reasoning so future reviewers (human or bot) don't have to re-derive it.	4 weeks ago
Rene Cannao	ca145d5026	fix(pgsql): atomic shutdown flag; honor dns_lookup fallback contract ... GloPgMon->shutdown was a plain bool, written by main.cpp's teardown and read by the monitor / DNS resolver loops on worker threads — a data race that can let the loops spin past shutdown or observe a stale value indefinitely. Promote to std::atomic<bool> and switch the readers/writer to acquire/release ordering. PgSQL_Monitor::dns_lookup() was also returning an empty string when GloPgMon / dns_cache_thread weren't initialized yet, ignoring the return_hostname_if_lookup_fails contract. Move the fallback out of the dns_cache_thread branch so startup / shutdown behave like a normal cache miss for callers that asked for the hostname fallback. Addresses CodeRabbit review feedback on PR #5806.	4 weeks ago
Rene Cannao	f2b53ea6e3	Address findings from independent diff review ... A subagent code review on top of the CodeRabbit + Gemini bot reviews found five additional issues that the bots missed. All five are fixed here. 1. LOAD PGSQL SERVERS TO RUNTIME was waking MySQL's resolver, not PgSQL's. PgSQL_HostGroups_Manager::commit() inherited a MySQL_Monitor::trigger_dns_cache_update() call from a copy of the MySQL HGM, so after a LOAD pgsql hostnames had to wait for the refresh interval (default 60 s) before becoming resolvable — defeating the warm-cache-before-traffic intent that motivated issue #5768. Route to PgSQL_Monitor::trigger_dns_cache_update(). Verified directly: with refresh_interval=60000 ms, inserting a pgsql_servers row + LOAD now produces record_updated=1 within ~4 s instead of waiting a full minute. 2. DNSResolverWorker could deadlock shutdown. monitor_dns_resolver_thread isn't noexcept (vector growth, set_thread_name, etc. can throw); if it threw, the std::promise on DNS_Resolve_Data was never satisfied, the producer's future::get() blocked forever, the resolver loop never reached the shutdown check, and pthread_join in main hung. Wrap the call in try/catch and force-satisfy the promise with a failure result on any uncaught exit. 3. Test step 3 wasn't actually exercising the connect-path lookup it claimed. hammer_proxy() routes through the proxy front-end, which in standard test infra resolves through the default hostgroup — typically configured with an IP literal (see e.g. test/infra/docker-pgsql16-single/conf/proxysql/config.sql). IP literals bypass dns_lookup via validate_ip(), so the dns_cache_queried bumps observed came from the resolver loop alone, not from the connect path. Step 3 would have passed even if PgSQL_Connection::connect_start_DNS_lookup() was wired up wrong. Install a pgsql_query_rules row from inside the test that routes testuser to hostgroup 999, so the proxy actually calls into the cache on client connects. Clean up the rule in the test exit path. 4. Use-after-move in the _dns_cache_update debug log. Both PgSQL_Monitor::_dns_cache_update and MySQL_Monitor::_dns_cache_update logged debug_iplisttostring(ip_address) after std::move'ing ip_address into add_if_not_exist(). The moved-from vector is in a "valid but unspecified" state — typically empty — so the log printed "IP:[]" instead of the IPs. Capture the string before the move. Same bug also fixed in the bookkeeper expired-record requeue path inside PgSQL_Monitor::monitor_dns_cache. 5. monitor_dns_cache had inconsistent indentation inside the `if (hostnames.empty()) { ... } else { ... }` block introduced when I wrapped the original goto-based control flow. The braces were correct but the body sat at the wrong tab depth, making the scope visually misleading and prone to mis-edits. Re-indented. Findings deliberately skipped from the review (rationale in commit body): - "thread_local shared_ptr<DNS_Cache> keeps stale cache alive across GloPgMon recreate" — pre-existing MySQL pattern; GloPgMon is never destroyed mid-process today. - "PgSQL_monitor_dns_cache_pthread can deref GloPgMon during a tight shutdown" — shutdown ordering in main.cpp sets GloPgMon->shutdown before joining the thread and deletes GloPgMon only afterwards, matching the MySQL pattern. - "cache only seeded on ASYNC_CONNECT_SUCCESSFUL" — matches MySQL; pre-existing scope choice. - "validate_ip rejects bracketed IPv6" — pre-existing in MySQL; no current configuration path produces bracketed IPv6 in pgsql_servers. - "Test relies on outbound DNS for example.com" — matches the upstream MySQL test_dns_cache test which uses google.com / yahoo.com / amazon.com. Established convention. - "ai_family hard-coded to AF_UNSPEC for PgSQL" — already commented in code; follow-up if/when pgsql-resolution_family is added.	4 weeks ago
Rene Cannao	a62d1b4e99	Address CodeRabbit + Gemini review feedback ... Fixes for actionable findings on PR #5806: DNS_Cache.cpp / hpp: - lookup(): initialize *ip_count = 0 on the disabled-cache fast path so callers don't observe a stale count from a previous lookup (CodeRabbit). - add_if_not_exist(): only bump counter_record_updated_ when an insert actually happened, and return that signal to callers. Previously a no-op call inflated the cache-update stats (CodeRabbit). - get_connected_peer_ip_from_socket(): drop the malloc, switch to a stack sockaddr_storage, and only assign result on AF_INET / AF_INET6 with a successful inet_ntop. Previously, on an unknown address family, we'd copy the uninitialized ip_addr buffer into result (Gemini + CodeRabbit). - monitor_dns_resolver_thread(): cache_ttl is signed int and at the max configured TTL (7*24*3600*1000 ms) `1000 * cache_ttl` overflows before being added to monotonic_time(). Force the multiply into unsigned long long space with 1000ULL (Gemini). - DNS_Cache::IP_ADDR::counter is now mutable so get_next_ip() (const) can __sync_fetch_and_add it without a const_cast (Gemini). PgSQL_Monitor.cpp: - monitor_dns_cache(): refresh pgsql_thread___monitor_local_dns_* before the loop, not just on the first version-bump. Otherwise the resolver runs its first pass against zero-initialized TTL / refresh interval and starts in the wrong enabled/disabled state until a later config bump (CodeRabbit). test/tap/tests/pgsql-test_dns_cache-t.cpp: - Step 7 ("Cache disabled by refresh_interval=0") was inserting an IP literal (0.0.0.0), which bypasses DNS regardless of the cache state. Switched to a resolvable hostname (example.com) so a regression in the cache-disable path would actually move counters and fail the assertion. Added a third assertion on dns_cache_lookup_success for symmetry. Plan adjusted to 17. Deliberately skipped: - CR comment about mysql_thread___resolution_family change requiring a cache flush: pre-existing MySQL behavior, out of scope for this PR. - CR comment about pthread_attr_init / setstacksize return checks in main.cpp: matches the existing un-checked pattern in MySQL_Monitor::run(). No need to diverge here. - Gemini comment about persistent thread pool vs. per-iteration spawn: MySQL_Monitor::monitor_dns_cache() also recreates the resolver threads each loop iteration; the PgSQL variant follows the same pattern. - Gemini comment about 2048-byte stack size: Thread::start takes ss in KB (lib/thread.cpp:46 `pthread_attr_setstacksize(&attr, ss*1024)`), so 2048 here means 2 MB, matching the MySQL resolver pool.	4 weeks ago
Rene Cannao	c10b30523c	Test: cover pgsql DNS cache + fix whitespace handling ... Adds pgsql-test_dns_cache-t mirroring the existing MySQL test_dns_cache test, exercising 16 scenarios: * pgsql-monitor_local_dns_cache_* variables propagate to runtime * IP literal does not touch the cache * Resolvable hostname populates dns_cache_record_updated * Client connect through the proxy increments dns_cache_queried and dns_cache_lookup_success on a cache hit * Hostname with leading/trailing whitespace is trimmed before resolution * Unresolvable hostname is queried but produces no record (cache miss bumps dns_cache_queried only) * Removing pgsql_servers rows drops the orphaned cache record * Cache disabled via refresh_interval=0 flatlines all counters * MySQL DNS cache counters do not move in response to pgsql-side activity (independence between the two caches) While writing the test, step 4 (whitespace trim) caught a real bug: PgSQL_Monitor::monitor_dns_cache was inserting hostnames verbatim from the SQLite3_result into the resolver queue, so ' example.org ' was handed to getaddrinfo() unchanged and failed. MySQL_Monitor sidesteps this by reading via SELECT trim(hostname) FROM monitor_internal.*; the pgsql variant reads directly from pgsql_servers_to_monitor so it needs to call trim() in C++. Fix: trim before validate_ip / insert into the hostnames set. The lookup path already trimmed, so the bookkeeper key now matches. Registered the test in groups.json under legacy-g4 and the mysql-* variant g4 groups, matching how the other pgsql-* tests are grouped.	4 weeks ago
Rene Cannao	a19894427e	Add independent DNS cache for PgSQL ... Fixes the watchdog asserts under DNS degradation reported in #5768. Symptom: with a PgSQL backend addressed by hostname, an unhealthy resolver made every PQconnectStart() block ~5s on getaddrinfo inside libpq. Under load, all PgSQL_Thread workers spent the bulk of each loop iteration in that synchronous DNS call, atomic_curtime fell behind the watchdog threshold (poll_timeout + 1s), and after restart_on_missing_heartbeats misses the watchdog asserts. MySQL avoids this because mysql-monitor's DNS cache lets MySQL_Connection::connect_start pass an IP directly to libmariadb; PgSQL had no equivalent. This change adds the equivalent for PgSQL, with state fully independent of the MySQL cache: * PgSQL_Monitor gains its own DNS_Cache, force_dns_cache_update flag, and dns_cache_{queried,lookup_success,record_updated} counters. PgSQL_Monitor::dns_lookup / update_dns_cache_from_pgsql_conn / trigger_dns_cache_update mirror the MySQL_Monitor surface. * A new background thread (PgSQL_monitor_dns_cache_pthread) drives PgSQL_Monitor::monitor_dns_cache(), which walks PgHGM->pgsql_servers_to_monitor and feeds the shared DNSResolverWorker pool. Launched alongside PgSQL_monitor_scheduler and lives independently of pgsql-monitor_enabled, matching MySQL. * PgSQL_Connection::connect_start now consults the cache. On a hit it appends `hostaddr=<ip>` to the libpq conninfo while keeping `host=<hostname>`; libpq documents this combo specifically to skip name resolution while preserving TLS hostname verification. On a miss / IP literal / disabled cache we fall back to the previous behavior (libpq does getaddrinfo). * Successful PgSQL connects seed the cache via update_dns_cache_from_pgsql_conn, so the second connect avoids getaddrinfo even before the resolver loop has visited the host. * The pgsql-monitor_local_dns_cache_ttl / _refresh_interval / _resolver_queue_maxsize variables (already accepted by Admin via PgSQL_Thread's variable registry) now actually propagate to pgsql_thread___monitor_local_dns_* globals. The propagation block in PgSQL_Thread::refresh_variables was previously commented out, so the values never reached anywhere. * The runtime stats output (SQL3_GlobalStatus) now exposes the PgSQL_Monitor_dns_cache_* counters alongside the existing PgSQL_Monitor_* counters. DNSResolverWorker is shared infrastructure added to DNS_Cache.hpp/cpp, used here by PgSQL_Monitor. MySQL_Monitor still uses its existing ConsumerThread-based pool; nothing about the MySQL cache changes.	4 weeks ago
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.	2 months 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.	2 months 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.	3 months ago
Rahim Kanji	fec7c12a35	feat: apply per-server SSL params in PgSQL monitor connections	3 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.	4 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.	4 months ago
Javier Jaramago Fernández	ba5af979ff	feat-wip: Add replication lag support for PostgreSQL monitoring	4 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	4 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	4 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)	5 months ago
Rene Cannao	2dfd61a958	Replace remaining direct sqlite3_* calls with proxy_sqlite3_* equivalents (address code-review)	5 months ago
René Cannaò	d43ae6e121	Surgical fixes for macOS compatibility: headers, types, and Makefile linking	5 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	7 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