pg_ivm 1.17 repairs PostgreSQL incremental-view restore bugs that could duplicate maintenance triggers

The pg_ivm development group announced version 1.17 on October 26, 2026. It adds a replace option to restore_immv() and a --pg-upgrade mode for pg_ivm_dump_metadata to address metadata entries left behind during PostgreSQL upgrades. It fixes restore_immv() incorrectly leaving the ispopulated flag false, which could cause a later refresh_immv() to create a duplicate set of incremental-view triggers and lead to incorrect maintenance. The release also improves automatic unique-index derivation, fixes a crash involving LATERAL subqueries during index creation and addresses compatibility assertions.

pg_ivm maintains materialised views immediately through triggers when base tables change, avoiding full refreshes for some workloads. That convenience depends on correct metadata and trigger state, especially across dump/restore and pg_upgrade. A restore that appears successful but later creates duplicate triggers is an operational correctness risk, not merely a performance issue. Administrators using pg_ivm should evaluate 1.17 before upgrade or restore work, verify trigger state and view results, and test under their supported PostgreSQL versions. The community announcement is authoritative, but the GitHub release listing inspected during this pass had not yet shown a v1.17 tag.

Previously restore_immv() could leave ispopulated=false after restoring an incrementally maintainable materialised view. A subsequent refresh_immv() might then create duplicate maintenance triggers. The release states that this could cause incorrect view maintenance. Operators should treat the bug as a reason to check restored view consistency and triggers, not assume every pre-1.17 database is corrupted.

pg_ivm 1.15 introduced metadata dump/restore helpers, but upgrading with pg_upgrade could retain old IMMV metadata entries. Version 1.17 adds replace semantics and a --pg-upgrade option to generate commands suitable for that path. The correct procedure depends on the installed extension and PostgreSQL versions; use current project instructions and test on a copy first.

The extension now derives unique keys from the original view definition instead of only a rewritten query, helping views containing EXISTS clauses obtain automatic indexes when uniqueness is provable. It also rejects set-returning target expressions that cannot provide unique keys and fixes a crash during index creation with LATERAL subqueries.

pg_ivm updates views in the same transaction as base-table changes. This can be efficient for small incremental modifications but costly for large or frequent bulk writes. Its supported SQL shapes and preload configuration remain constrained; version 1.17 does not turn it into general-purpose automatic materialised-view maintenance.