PgDog supports hot-reloading its configuration at runtime by sending SIGHUP to the process, or by connecting to the admin database and issuing RELOAD. This is intended to let operators tweak settings (routing, load balancing, pool sizes, etc.) without dropping active client or server connections. PgDog also exposes real-time internal statistics via the admin console (SHOW STATS, SHOW CLIENTS, SHOW POOLS, etc.) .
Currently, any reload, whether triggered by a no-op config re-apply or by an actual topology change (e.g., Patroni failover promoting a new primary, a replica being added/removed), resets all pool and topology statistics to zero. This is overly aggressive: even when the topology changes, most existing nodes (shards, replicas, primary) typically remain the same between reloads. Only the delta (added/removed/promoted nodes) should be treated as new or torn-down pools.
Impact / Use Cases:
-
HA failover monitoring: In Patroni-managed clusters, a primary/replica swap is common and expected; PgDog should treat the promoted node's pool as a continuation (matched by node identity, not by role) rather than wiping its stats.
-
Elastic scaling scenarios: When adding a new read replica or shard, existing pools shouldn't lose history just because the overall topology map changed, only the new node's pool should start fresh.
-
Incident correlation across failovers: Engineers debugging an outage that spans a failover event need pre- and post-failover stats on the same underlying node to see whether a problem followed the connection or the role.
-
Capacity planning accuracy: Long-running trend analysis (e.g., total queries per node, peak wait times) becomes far more reliable if minor topology churn doesn't erase months of accumulated counters for nodes that never actually left the cluster.
-
Reduced noise in dashboards: Grafana/Prometheus dashboards built on PgDog metrics would stop showing false "zero" dips at every reload, reserving real drops for actual node removal/restart events.
PgDog supports hot-reloading its configuration at runtime by sending SIGHUP to the process, or by connecting to the admin database and issuing RELOAD. This is intended to let operators tweak settings (routing, load balancing, pool sizes, etc.) without dropping active client or server connections. PgDog also exposes real-time internal statistics via the admin console (SHOW STATS, SHOW CLIENTS, SHOW POOLS, etc.) .
Currently, any reload, whether triggered by a no-op config re-apply or by an actual topology change (e.g., Patroni failover promoting a new primary, a replica being added/removed), resets all pool and topology statistics to zero. This is overly aggressive: even when the topology changes, most existing nodes (shards, replicas, primary) typically remain the same between reloads. Only the delta (added/removed/promoted nodes) should be treated as new or torn-down pools.
Impact / Use Cases:
HA failover monitoring: In Patroni-managed clusters, a primary/replica swap is common and expected; PgDog should treat the promoted node's pool as a continuation (matched by node identity, not by role) rather than wiping its stats.
Elastic scaling scenarios: When adding a new read replica or shard, existing pools shouldn't lose history just because the overall topology map changed, only the new node's pool should start fresh.
Incident correlation across failovers: Engineers debugging an outage that spans a failover event need pre- and post-failover stats on the same underlying node to see whether a problem followed the connection or the role.
Capacity planning accuracy: Long-running trend analysis (e.g., total queries per node, peak wait times) becomes far more reliable if minor topology churn doesn't erase months of accumulated counters for nodes that never actually left the cluster.
Reduced noise in dashboards: Grafana/Prometheus dashboards built on PgDog metrics would stop showing false "zero" dips at every reload, reserving real drops for actual node removal/restart events.