OffNet Newsroom

Daily topic roundup

Database Technology

Friday, August 21, 2026 · 8 stories, curated & summarized — click any story for the source.

Share this roundup on LinkedIn Full edition
Percona Blog database

PMM 3.9.0 and Below: Privileged ClickHouse Access via Grafana Source

Percona disclosed a high-severity vulnerability in PMM versions 3.9.0 and earlier that allows unauthorized privileged access to ClickHouse through the Grafana data source integration. This flaw potentially exposes underlying database metrics and infrastructure details to attackers who can interact with the Grafana interface. Immediate remediation is required to prevent exploitation of this specific vector within the monitoring stack.

  • Audit PMM instances running 3.9.0 or earlier for immediate exposure risk.
  • Restrict Grafana data source permissions to limit ClickHouse query scope.
  • Apply Percona's latest security patch to close the privilege escalation path.
  • Monitor Grafana logs for anomalous queries originating from the PMM source.

Fleet impact: This affects Oracle ExaCC and AWS Aurora fleets monitored by PMM, as the vulnerability targets the ClickHouse backend used for metrics storage. Verify your PMM version and update immediately to prevent attackers from querying raw metrics data that could reveal infrastructure topology or performance baselines.

CHECKLISTSecure PMM Against ClickHouse ExploitAudit PMM instances version 3.9.0 or earlierRestrict Grafana data source permissions immediatelyApply Percona's latest security patchMonitor Grafana logs for anomalous queries
Read at source →
Planet PostgreSQL database

Postgres 19: Retrospective on Load, Storage, and Indexing Advice

Crunchy Data revisits historical best practices for PostgreSQL data loading, storage, and indexing to determine their validity for the upcoming Postgres 19 release. While much of the foundational advice from versions 10 and 11 remains accurate, several key features have changed the landscape. The analysis highlights significant updates including async I/O improvements, resilient COPY operations, and new indexing capabilities like skip scan and enhanced BRIN support.

  • Async I/O now accelerates scans and vacuum operations on modern storage hardware.
  • LZ4 compression is now the default, impacting storage efficiency and CPU usage.
  • Skip scan and richer BRIN index shapes offer new optimization paths for queries.
  • Partition operations are smoother, reducing operational friction during schema changes.
  • Core indexing and storage advice from PG 10/11 remains largely valid for PG 19.
Read at source →
AWS Database Blog awsdatabase

AWS blog: Replicating SQL Server full-text search in PostgreSQL

Migrating full-text search from SQL Server to PostgreSQL often yields silent result discrepancies due to differences in text handling, linguistics, and accent treatment. This AWS Database Blog post details methods to reproduce SQL Server search behavior on Amazon Aurora PostgreSQL and RDS for PostgreSQL. It covers critical adjustments for collation, tokenization, accent-insensitive queries, and synonym management.

  • SQL Server and PostgreSQL handle text and accents differently, risking silent search result drift.
  • Explicitly configure collation and tokenization to match legacy SQL Server behavior.
  • Implement accent-insensitive search logic to maintain user experience parity.
  • Map synonyms carefully to ensure consistent retrieval across both engines.
Read at source →
Planet PostgreSQL database

PostgreSQL tests shared hash tables for faster parallel aggregation

Andrei Lepikhov investigates whether shared hash tables can accelerate parallel aggregation in PostgreSQL by decoupling group lookups from lock contention. A working patch set was developed and benchmarked on Google Cloud many-core instances to validate the hypothesis from a recent paper. The findings assess if this approach effectively reduces LWLock bottlenecks and improves query plan performance.

  • Shared hash tables offer a potential path to faster parallel aggregation in PostgreSQL
  • Decoupling group lookups from locks is key to reducing contention
  • Benchmarks confirm viability on high-core Google Cloud instances
  • Approach may be reusable for other query plan operations
  • Trade-offs and costs of this method are explicitly analyzed
CHECKLISTOptimizing PostgreSQL AggregationImplement shared hash tables for parallel aggregationDecouple group lookups from LWLock contentionBenchmark on many-core cloud instancesAnalyze trade-offs for other operations
Read at source →
Planet PostgreSQL database

PostgreSQL lock_timeout prevents migration starvation behind long queries

Christophe Pettus explains how configuring lock_timeout acts as a safeguard during schema migrations or heavy workloads. By setting a limit on how long a transaction waits for a lock, the database prevents slow queries from blocking critical operations indefinitely. This mechanism ensures that time-sensitive tasks maintain priority and do not get stuck behind resource-heavy processes.

  • Use lock_timeout to enforce SLAs for critical operations during maintenance windows
  • Prevents long-running queries from blocking schema changes or DDL statements
  • Configurable per-session or globally to balance stability vs. concurrency
  • Reduces risk of cascading timeouts in application layers by failing fast in DB
Read at source →
Planet PostgreSQL database

Bertrand Drouvot introduces pg_shmemviz for PostgreSQL shared memory analysis

Bertrand Drouvot has released pg_shmemviz, a development and debugging tool that captures PostgreSQL shared memory segments into offline snapshots. Unlike existing views that show logical allocations, this tool exposes the physical layout, byte-level details, and C structure padding of memory regions. It allows engineers to navigate raw bytes and trace pointers to understand exactly how memory is utilized at a granular level.

  • Provides physical layout visibility beyond logical allocations shown in pg_buffercache
  • Enables byte-level navigation and inspection of C structure fields and padding
  • Captures main and dynamic shared memory into offline snapshots for deep debugging
  • Follows the established pg_walviz approach applied to shared memory segments
CHECKLISTpg_shmemviz CapabilitiesReveals physical memory layout beyond logical viewsInspect bytes, fields, and structure paddingCapture offline snapshots of shared memoryFollows pg_walviz open-source pattern
Read at source →
Planet PostgreSQL database

Prevent Duplicate Submissions in Next.js Using Idempotency Keys and PostgreSQL

Duplicate form submissions often stem from client retries, network timeouts, or queue redeliveries rather than frontend bugs. This approach leverages stable idempotency keys, enforced by PostgreSQL constraints, to ensure side effects occur only once. It integrates transactional outbox patterns and safe retry logic to handle distributed system failures gracefully.

  • Use idempotency keys to deduplicate requests across retries and timeouts.
  • Enforce uniqueness at the database level via PostgreSQL constraints.
  • Implement transactional outbox to decouple processing from persistence.
  • Add reconciliation jobs to handle edge cases in distributed failures.
Read at source →
Planet PostgreSQL database

pg_statviz 1.2 adds PostgreSQL 19 support and blocking locks analysis

pg_statviz 1.2 has been released with full support for PostgreSQL 19, including capture of the new wal_fpi_bytes counter from pg_stat_wal. The update enhances snapshot_conf by recording I/O worker details, WAL levels, and autovacuum scoring settings. A new module now tracks blocking and blocked sessions with breakdowns by lock type using pg_blocking_pid.

  • Captures new wal_fpi_bytes metric from pg_stat_wal in PG19
  • Records I/O worker, WAL level, and autovacuum settings in snapshot_conf
  • Analyzes blocking locks with session counts and lock type breakdowns
  • Tested against PG19 beta3 and supports PG13 through PG19 range
CHECKLISTpg_statviz 1.2 Key UpdatesSupports PostgreSQL 19 through 13Captures wal_fpi_bytes from pg_stat_walTracks blocking and blocked sessionsRecords I/O worker and WAL details
Read at source →
↑