OffNet Newsroom

Daily topic roundup

Database Technology

Tuesday, July 07, 2026 · 8 stories, curated & summarized — click any story for the source.

Planet PostgreSQL database

Postgres 14-16 Replication Deadlock Bug Affects WAL Replay

Minor releases 14.23, 15.18, and 16.14 introduced a regression causing a MultiXactOffsetSLRU deadlock during WAL replay. This issue can halt streaming replication standbies or block point-in-time recovery operations. The bug was first reported on May 20th and has since generated multiple reports across mailing lists and support channels.

  • Affected versions: Postgres 14.23, 15.18, and 16.14.
  • Deadlock occurs during WAL replay, not standard query execution.
  • Streaming replication standbies may hang indefinitely.
  • Point-in-time recovery (PITR) processes can also stall.
  • Monitor replication lag and recovery logs for signs of this deadlock.

Netflix engineers deployed a metadata-driven dynamic partition splitting mechanism to resolve wide partition issues in time series workloads. The system automatically detects oversized partitions, divides them into smaller units, and routes read requests across these child partitions. This approach successfully lowered read latency to the millisecond range, reduced timeouts, and enhanced cluster stability without requiring application-level changes.

  • Dynamic splitting addresses wide partition hotspots that cause second-level read latencies in time series data.
  • Metadata-driven detection allows automatic partitioning without manual schema changes or application code updates.
  • Read routing across child partitions ensures load distribution and improved cluster stability under heavy load.
  • Timeouts are significantly reduced as the system prevents single-node bottlenecks from oversized partitions.
HOW IT WORKSDynamic Partition Splitting Pipeline1Detect oversized partitions via metadata2Automatically divide into smaller units3Route reads across child partitions4Maintain cluster stability under load

Christophe Pettus examines the enable_partitionwise_aggregate GUC, which defaults to off in PostgreSQL. Enabling this setting allows the planner to perform aggregation directly on partitioned tables, potentially improving query performance. The trade-off involves increased memory usage during execution, requiring careful evaluation of whether the speed gain justifies the resource cost for specific workloads.

  • The parameter defaults off, requiring explicit enablement for partitioned aggregation.
  • Enabling it trades higher memory consumption for faster query execution times.
  • DBAs must evaluate if the speed benefit outweighs memory costs for their queries.
  • This optimization specifically targets partitioned table aggregation strategies.
Planet PostgreSQL database

PostgreSQL 20 adds per-backend lock stats via pg_stat_lock

Michael Paquier committed a patch for PostgreSQL 20 that introduces per-backend lock statistics. This feature exposes lock wait counts, wait times, and fast-path exceeded counts for individual backends. The data mirrors existing information available through pg_stat_lock but allows for more granular monitoring at the session level.

  • PostgreSQL 20 gains per-backend visibility into lock contention metrics.
  • Monitor lock wait counts and durations to pinpoint specific blocked sessions.
  • Track fast-path lock acquisition failures to identify performance bottlenecks.
  • No immediate action required for current releases; plan for PG 20 upgrade.
CHECKLISTPer-Backend Lock Monitoring StepsEnable per-backend lock statistics in PostgreSQL 20Monitor lock wait counts and durations per sessionTrack fast-path lock acquisition failures for bottlenecksPlan upgrade to PG 20 for granular visibility

The presence of .ready files in pg_wal/archive_status indicates that WAL segments have been generated and are available for transport via streaming replication or archive_command. These files accumulate before being marked as .done once the receiving side confirms consumption. A growing pile of .ready files is a strong signal of stalled WAL delivery rather than a broken replica, often pointing to network or consumer latency issues.

  • .ready files mean WAL is generated and waiting for transport, not necessarily that replication is broken.
  • Consumption by streaming replicas or archive_command moves files to .done status.
  • Accumulating .ready files usually indicate slow transport or a stalled consumer.
  • Check network latency and replica replay speed when disk usage climbs due to .ready files.
HOW IT WORKSWAL Replication Lifecycle1WAL segment generated2.ready file created3Transported to replica4Consumer confirms receipt5Marked as .done

pg_hardstorage deliberately omits the incremental chain found in formats like pgBackRest or Barman to eliminate a critical single point of failure. In traditional chained models, corruption or deletion of any single backup in the sequence renders all subsequent backups invalid. This design choice prioritizes resilience against storage-level issues such as bit flips or lifecycle policy errors over the space efficiency of chaining.

  • Avoids the 'chain footgun' where one corrupted backup invalidates the entire recovery path.
  • Resilient to S3 lifecycle deletions or bit flips that would break traditional incremental chains.
  • Recovery does not depend on the sequential integrity of previous backup artifacts.
  • Design prioritizes fault isolation over the storage savings of strict incremental dependencies.
GitHub Trending (daily) githubrepos ⚠ unverified date/source

Alibaba releases zvec, an in-process vector DB with native FTS and hybrid search

Alibaba Group has open-sourced zvec, a lightweight vector database designed to run in-process within applications. The latest v0.5.0 release introduces native full-text search and hybrid retrieval capabilities, allowing combined queries across dense vectors, sparse vectors, and scalar filters without external search engines. It utilizes a DiskANN index for production-grade similarity search.

  • Embeds directly into apps, eliminating external vector DB infrastructure overhead.
  • Native full-text search removes dependency on separate search engines like Elasticsearch.
  • Supports hybrid retrieval combining vector, sparse, and scalar filters in one query.
  • Uses DiskANN indexing for low-latency, scalable similarity search.
TRADE-OFFzvec vs Traditional StackTraditional StackSeparate vector DBExternal search engineHigh infrastructure overheadzvec ApproachIn-process integrationNative full-text searchUnified hybrid queriesvs
Planet PostgreSQL database

PostgreSQL VACUUM: Byte-Level Page Analysis

This article moves beyond standard autovacuum tuning to examine VACUUM operation byte by byte. It contrasts page-level HOT pruning shortcuts with full VACUUM processes required for cold updates, deletes, and index cleanup. The author provides detailed snapshots of pages before and after each phase to illustrate internal mechanics.

  • HOT pruning is limited to single pages and HOT tuples only.
  • Full VACUUM handles cold updates, deletes, and index entry cleanup.
  • Byte-level analysis reveals exact state changes during vacuum phases.
  • Visibility map and free space map updates require dedicated vacuum work.