OffNet Newsroom

Daily topic roundup

Database Technology

Wednesday, August 05, 2026 · 7 stories, curated & summarized — click any story for the source.

Idle sessions in PostgreSQL occupy backend memory and connection slots without holding locks or advancing xmin. The idle_session_timeout GUC allows the database to automatically terminate these sessions after a specified duration. This helps prevent connection pool saturation and reduces resource consumption from abandoned client connections.

  • Idle sessions consume backend memory and connection slots, not locks or xmin.
  • Configure idle_session_timeout to automatically reap abandoned client connections.
  • Coordinate timeout values with your connection pooler to avoid premature drops.
  • Monitor connection metrics to ensure poolers and timeouts work in harmony.

pgAdmin 4 version 9.17 is now available, addressing seven distinct security vulnerabilities identified in the CVE-2026-17346 through CVE-2026-17566 range. This update also delivers 28 additional bug fixes and introduces new features such as logging authenticated user identities in HTTP access logs. Key usability improvements include an opt-in Gateway API HTTPRoute template for Helm charts and a configurable row count cap for the View Data action to handle large tables more efficiently.

  • Patch immediately to resolve seven critical security vulnerabilities in pgAdmin 4.
  • Enable HTTP access log identity tracking for better audit trails and security monitoring.
  • Use the new Gateway API HTTPRoute template in Helm charts as an alternative to Ingress.
  • Configure row count limits in View Data to prevent performance issues on large tables.
BY THE NUMBERSSeven Critical Fixes in pgAdmin 4 v9.177Security vulnerabilities patchedCVE-2026-17346 through CVE-2026-17566 resolved
Percona Blog database ↺ since 08-01

Percona Server MySQL stored procedures memory behavior under benchmarking

Percona researchers investigating memory allocator performance in Percona Server for MySQL discovered unexpected memory consumption patterns linked to stored procedures. The findings emerged during benchmarking and reveal details that warrant deeper explanation beyond the original performance comparison goals. These results highlight specific memory behaviors that may impact server resource planning.

  • Stored procedures exhibit unique memory allocation characteristics in Percona Server for MySQL.
  • Memory allocator choices significantly influence observed performance and consumption metrics.
  • Benchmarking stored procedures requires accounting for these specific memory overheads.
  • Review Percona's detailed analysis to understand the root causes of these memory effects.
CHECKLISTMySQL Stored Proc Memory TipsAccount for unique memory allocation patternsSelect memory allocators carefullyInclude overhead in benchmarksReview Percona's root cause analysis
Planet PostgreSQL database ↺ since 08-01

PostgreSQL 18 Introduces extension_control_path for OCI Extension Containers

PostgreSQL 18 adds a Grand Unified Configuration (GUC) named extension_control_path, allowing extension control and SQL files to reside outside the server's installation directory. This change enables packaging extensions as independent OCI container images that can be mounted at runtime via Kubernetes ImageVolume or Docker volumes. The approach supports decoupling extension versions from the core server image, though its effectiveness depends on the specific extension's architecture and dependencies.

  • New GUC extension_control_path decouples extension files from the PostgreSQL server binary tree.
  • Enables packaging extensions as standalone OCI containers mounted at runtime in Kubernetes or Docker.
  • Reduces server image rebuilds by allowing independent versioning of extensions like pgvector.
  • Decoupling benefits vary; complex extensions with deep system integration may not gain value.
HOW IT WORKSOCI Extension Deployment Flow1Package extension as OCI image2Mount image at runtime3Set extension_control_path GUC4PostgreSQL loads extension files
AWS What's New awsdatabase ↺ since 08-04

AWS Transform supports offline schema migration from SQL Server to Aurora PostgreSQL

AWS Transform for Windows modernization now allows offline source transformation, enabling customers to migrate Microsoft SQL Server databases to Amazon Aurora PostgreSQL without live connections. The service uploads DDL files to assess complexity, converting storage objects via AWS DMS and stored procedures using an agentic interface. This facilitates direct modernization of legacy .NET applications by decoupling schema analysis from active database access.

  • Offline migration removes dependency on live SQL Server availability during schema assessment.
  • DDL upload enables early complexity analysis for stored procedures and storage objects.
  • Agentic tooling assists in converting SQL Server code to Aurora PostgreSQL equivalents.
  • Streamlines legacy .NET app modernization by separating schema work from cutover.
HOW IT WORKSOffline SQL Server Migration Steps1Upload DDL files2Assess complexity3Convert storage objects4Transform stored procedures5Migrate to Aurora
PostgreSQL News database ↺ since 08-04

pgBackRest 2.59.0 Released with Enhanced Backup and Restore Capabilities

The pgBackRest community has released version 2.59.0, a reliable backup and restore solution designed for large databases. This update includes support for parallel backup and restore operations, block incremental backups, and multiple compression types. It also features malware and ransomware protection, per-file checksums, and encryption options.

  • Upgrade to pgBackRest 2.59.0 for improved backup performance and reliability.
  • Leverage block incremental backups to reduce storage usage and backup times.
  • Implement malware and ransomware protection for enhanced security.
  • Utilize multiple compression types and encryption for optimized storage.
  • Ensure per-file checksums are enabled for data integrity verification.
CHECKLISTPgBackRest 2.59 Key FeaturesUpgrade to version 2.59 for reliabilityUse block incremental backups to save spaceEnable malware and ransomware protectionApply multiple compression types and encryptionVerify integrity with per-file checksums
Planet PostgreSQL database ↺ since 08-04

Postgres COUNT(DISTINCT) Slow? Use HLL Sketches for 2x Speed and Merging

Elizabeth Garrett Christensen demonstrates that HyperLogLog (HLL) approximations can halve query latency compared to exact COUNT(DISTINCT) by avoiding full distinct scans. The technique involves hashing values into compact 1.3 KB sketches that can be pre-aggregated per day. These sketches are mergeable, allowing instant distinct counts across arbitrary date ranges by unioning daily rows rather than re-scanning raw data.

  • HLL provides ~2x speedup over exact COUNT(DISTINCT) on single scans
  • Sketches are tiny (1.3 KB/row) and independent of dataset size
  • Mergeable sketches enable instant cross-date-range distinct counts
  • Pattern: hash value, aggregate into HLL, query cardinality
  • Trade precision for massive performance gains in analytics