by Dilip Kumar, Cloud SQL for PostgreSQL
Google Cloud is committed to open source, and PostgreSQL is a cornerstone of managed database offerings, including Cloud SQL and AlloyDB.
Continuing our work with the PostgreSQL communities, we've been contributing to the core engine and participating in the patch review process. Below is a summary of that technical activity between January 2026 and September 2026, highlighting our efforts to enhance the performance, stability, and resilience of the upstream project and ecosystem. By strengthening these core capabilities, we aim to drive innovation that benefits the entire global PostgreSQL ecosystem and its diverse user base.
Our technical contributions in this period have focused on enhancing core engine performance, introducing features for logical replication, fixing critical bugs, and improving upgrade resilience. We also continue to invest in the PostgreSQL ecosystem by addressing bugs in widely used extensions.
Technical contributions: January 2026 – September 2026
Our contributions this cycle span four key areas:
- Logical replication and conflict management: Paving the way for active-active replication, enhanced conflict logging, and catalog safety.
- Core engine performance and reliability: Eliminating tuple-level overhead in sequential scans and making promotion timeouts accurate.
- Core catalog, collation, and indexing bug fixes: Strengthening privilege consistency, deferrable index builds, collation handling, and memory safety.
- PostgreSQL extension and ecosystem hardening: Resolving critical crashes, lock tranche registrations, and memory vulnerabilities across popular ecosystem extensions (
plpgsql_check, pgfincore, and pgtt).
1. Logical replication and conflict management
Logical replication is essential for near-zero downtime migrations, major version upgrades, and multi-region data distribution. Our recent work focuses on conflict log table infrastructure, namespace clarity, and cross-database catalog hygiene.
- Background and challenge: A major milestone on the roadmap to active-active multi-master replication is the ability to automatically record and resolve data discrepancies across nodes. Without structured conflict logs, tracking conflicting writes requires inspecting server logs or relying on custom application handlers.
- Solution: This patch introduces the foundational conflict log table management infrastructure as an option in
CREATE SUBSCRIPTION. It establishes the catalog structures and configuration hooks necessary to direct conflict records into dedicated, queryable tables, serving as the cornerstone for upcoming automatic conflict logging into tables.
- Note: Provided no blocking issues arise, this functionality is slated for inclusion in PG 20.
- Contributors: Dilip Kumar (Primary Author)
- Background and challenge: While
pg_subscription is physically a shared catalog so the background launcher process can scan all databases, subscription objects are logically local to each database. Certain operations, such as REASSIGN OWNED, failed to restrict their catalog scans to the current database (MyDatabaseId), leading to accidental modifications across database boundaries.
- Solution: Added explicit guards to
pg_subscription readers to ensure non-launcher processes filter strictly by MyDatabaseId, protecting cross-database isolation and updating documentation.
- Contributors: Dilip Kumar (Author)
- Background and challenge: When publishing tables with
EXCEPT clauses, check_publication_add_relation() previously reported only unqualified table names when a relation could not be processed, leading to ambiguous error messages in multi-schema databases.
- Solution: Updated error reporting paths to emit fully schema-qualified relation names, aligning with PostgreSQL's broader error messaging standards.
- Contributors: Dilip Kumar (Author)
2. Core engine performance and administrative enhancements
Optimizing throughput and improving the predictability of administrative operations remain top priorities for database workloads.
- Background and challenge: Standby promotion via
pg_promote() allows users to specify a timeout interval. Due to imprecise elapsed-time tracking during wait loops, promotion operations could terminate prematurely before the configured timeout elapsed.
- Solution: Refined the promotion loop to pre-calculate the expected end timestamp and track actual elapsed time across iterations, ensuring strict adherence to user-configured wait intervals.
- Contributors: Robert Pang (Reporter and Author)
- Background and challenge: Previously,
CheckXidAlive validation was executed inside the inner table_scan_next routines. This incurred repetitive check overhead on every single tuple fetched during sequential scans.
- Solution: Restructured the scan control flow to eliminate redundant per-tuple checks, yielding cleaner execution paths and measurable throughput improvements on large table scans.
- Contributors: Dilip Kumar (Author)
3. Core engine access control, collation, and indexing bug fixes
We continue to harden PostgreSQL's core engine against catalog inconsistencies, segmentation faults, and edge-case query anomalies.
- Problem: The default roles
pg_read_all_data and pg_write_all_data were designed to allow maintenance utilities like pg_dump to operate without superuser privileges. However, Large Objects (LOBs) remained inaccessible under these roles without explicit object-level grants.
- Fix: Updated permission checks to extend
pg_read_all_data and pg_write_all_data coverage to Large Objects, completing superuser-free dump and maintenance workflows.
- Contributors: Nitin Motiani (Author), Dilip Kumar (Reviewer)
- Problem: When building a replacement index during
REINDEX CONCURRENTLY for a deferrable unique constraint, index_create_copy() defaulted constraint flags to 0, setting the immediate property to true. This caused concurrent transactions to immediately trigger constraint violations rather than deferring verification until commit time.
- Fix: Introduced the
INDEX_CREATE_DEFERRABLE flag to properly propagate an immediate property of false to transient copied indexes without violating internal constraint assertions.
- Contributors: Nitin Motiani (Author)
- Problem: Following the addition of nondeterministic collation support for
LIKE, literal pattern substring parsing unconditionally skipped all backslash characters. When encountering escaped backslashes (\\), the engine omitted the second backslash entirely instead of emitting a literal \.
- Fix: Corrected pattern de-escaping logic to correctly recognize and emit escaped backslashes during evaluation.
- Contributors: Nitin Motiani (Author)
- Problem: If a backend encountered a
FATAL exit while holding a lock in a Dynamic Shared Memory (DSM) segment (e.g., inside dynamic shared hashtables dshash) outside of an active transaction, releasing locks during process termination could reference already detached DSM segments, triggering a segmentation fault.
- Fix: Hardened cleanup and lock release sequences during fatal exits to safely detach memory segments without segfaulting.
- Contributors: Dilip Kumar (Reviewer)
4. PostgreSQL ecosystem and extension hardening
Enterprise PostgreSQL architectures rely heavily on third-party extensions. Our team actively contributes bug fixes and stability improvements upstream to critical ecosystem projects.
- Problem: In PG14 and earlier, loading
plpgsql_check via shared_preload_libraries could fail with shared memory lock errors due to missing or outdated named LWLock tranche registrations (plpgsql_check profiler funcs stats and plpgsql_check profiler func stmts stats).
- Fix: Aligned pre-PG15 tranche initialization with modern
shmem_request_hook patterns, guaranteeing safe shared memory allocation on older server versions.
- Contributors: Aniket Jha (Author)
- Problem:
pgfincore contained two subtle memory corruption issues: an off-by-one array boundary access during buffer inspection and a dangling pointer assignment during deallocation.
- Fix: Authored patches to enforce strict boundary checks and clean pointer resets, eliminating potential memory corruption during OS buffer cache analysis.
- PRs: klando/pgfincore#12 and klando/pgfincore#13
- Contributors: Robert Pang (Author)
- Problem: When running utility commands via the extended query protocol or within cached contexts (such as PL/pgSQL and SQL functions),
pgtt modified cached statement parse trees in-place using short-lived query memory. Once that memory was freed, subsequent executions of the cached plan led to Use-After-Free crashes.
- Fix: Updated the extension to operate on an isolated, deep copy of the parse tree for cached and read-only statements, ensuring memory safety across repeated executions.
- Contributors: Sunaina Punyani (Author)
Related reading
Community roadmap: Your feedback matters
We encourage you to utilize the comments area to propose new capabilities or refinements you wish to see in future iterations, and to identify key areas where the PostgreSQL open source communities should focus their investments.
Acknowledgments
We would like to celebrate our engineers for their ongoing dedication to open source:
- Dilip Kumar (PostgreSQL Significant Contributor): Authoring and reviewing core replication, catalog, memory, and performance patches.
- Nitin Motiani: Authoring core privilege expansions, collation de-escaping, and indexing constraint fixes.
- Robert Pang: Authoring promotion timing fixes and hardening
pgfincore memory safety.
- Aniket Jha: Hardening
plpgsql_check shared memory lock mechanics.
- Sunaina Punyani: Resolving memory and execution safety in
pgtt.
We also extend our sincere gratitude to the wider PostgreSQL open source communities—especially the committers, reviewers, and extension maintainers—for their collaborative reviews and shared commitment to keeping PostgreSQL the world’s most advanced open source database.
Get high-quality video production right from your browser. Anyone with a Google account can create videos for free in Google Vids.
