Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tt6At-008b8Y-II for pgsql-announce@arkaria.postgresql.org; Fri, 14 Mar 2025 14:38:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tt6As-009F2g-8h for pgsql-announce@arkaria.postgresql.org; Fri, 14 Mar 2025 14:38:10 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tt6Ar-009F2U-DL for pgsql-announce@lists.postgresql.org; Fri, 14 Mar 2025 14:38:09 +0000 Received: from mahout.postgresql.org ([2001:4800:3e1:1::227]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1tt6An-002qny-0i for pgsql-announce@lists.postgresql.org; Fri, 14 Mar 2025 14:38:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Message-ID:Date:Reply-To:From:To:Subject: MIME-Version:Content-Type:Sender:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=x+PKZR9BJ879/G7I1VM5Zk5pcpChHnyYG46pcJIAyMM=; b=310XrqkCUEcWRbcES+pOciH2Gn Uvj4IE34dbG1HPSsNeMXg6SXLlL1zLE1hDQSJ7RS87ve9DyzYl/f8GKH1fH4GUeMogMRLAHfgrAD3 O5jNDeemJ42eUuCen5BzQlMW4rVxmEcxwMbL7C0yY+lMdFVa4bW2wIm9fZSEUOwMkIFHL2SK6jDYO WsSkOA5KsLxKMjb9q3cA4TWvnGX+OHNmECWp/UV0B+fTtQQOTTtmHw+AvHCD6+k65dGDwd3ZiIHNK NL14JULgdKil56zA3+ZIONL5IuxSPwXG8ftVT/8mZQ//2QcGRGncSju1UkBwnqE2QVYTLWdzlwRk7 G+LrMyhg==; Received: from wrigleys.postgresql.org ([2a02:16a8:dc51::60]) by mahout.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tt6Am-007HtB-T7 for pgsql-announce@lists.postgresql.org; Fri, 14 Mar 2025 14:38:05 +0000 Received: from localhost ([127.0.0.1] helo=wrigleys.postgresql.org) by wrigleys.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tt6Al-00Gppd-N7 for pgsql-announce@lists.postgresql.org; Fri, 14 Mar 2025 14:38:03 +0000 Content-Type: multipart/mixed; boundary="===============6296956721530049119==" MIME-Version: 1.0 Subject: pg_ivm 1.10 released To: PostgreSQL Announce From: IVM Development Group via PostgreSQL Announce Reply-To: nagata@sraoss.co.jp Date: Fri, 14 Mar 2025 14:37:29 +0000 Message-ID: <174196304985.680.17342387456989253416@wrigleys.postgresql.org> X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-pglister-tags: related X-pglister-tagsig: 2e540eb31510152bdb54a42b965bfe815bce8c58ca534cc9a5ba48089a4c7d11 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --===============6296956721530049119== Content-Type: multipart/alternative; boundary="===============1921304801497964898==" MIME-Version: 1.0 --===============1921304801497964898== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable IVM Development Group is pleased to announce the release of [pg_ivm 1.10]( = https://github.com/sraoss/pg_ivm/releases/tag/v1.10 ). Changes since the v1.9 release include: ### Bug Fixes * Fix a failure in DROP EXTENSION (Ishant Bhaskar ) Previously, dropping pg_ivm caused the error "could not open relation w= ith OID ..."=20 due to a hook function that allows DROP TABLE on an IMMV to remove its = entry from pg_ivm_immv. Additionally, issuing DROP TABLE concurrently with DR= OP EXTENSION pg_ivm could result in the same error.=20 * Prevent automatic index creation when using set-returning function (Yugo = Nagata) A unique index was previously created automatically even when a set-ret= urning=20 function appeared in the FROM clause, which led to errors due to key du= plication. * Change schema from pg_catalog to pgivm (Yugo Nagata) Previously, pg_upgrade failed due to permission issues because the pg_i= vm_immv=20 catalog was created in pg_catalog. To resolve this, all objects created= by pg_ivm have been moved to the pgivm schema, which is now created automatically= by=20 pg_ivm. Breaking Change: This affects compatibility with previous releases. If = you want to access objects like the create_immv function as before, you must either= qualify them with the pgivm schema or adjust your search_path accordingly. * Fixed view maintenance failures when a column is dropped from a table (Yu= go Nagata) When a table contained a dropped column, incremental view maintenance f= ailed with an error like: ```ERROR: could not find attribute 43 in subquery targetlist``` * Fix potential view inconsistency issues (Yugo Nagata) Previously, the view contents could become inconsistent with the base t= ables in the following scenarios: 1) A concurrent transaction modifies a base table and commits before the incremental view maintenance starts in the current transaction. 2) A concurrent transaction modifies a base table and commits before t= he create_immv or refresh_immv command generates data. 3) Concurrent transactions incrementally update a view with a self-join or modify multiple base tables simultaneously. These issues have now been resolved to ensure consistency. ### About pg_ivm pg_ivm is an extension module that provides Incremental View Maintenance (I= VM) feature. Incremental View Maintenance (IVM) is a way to make materialized views up-t= o-date in which only incremental changes are computed and applied on views rather tha= n recomputing.=20 pg_ivm provides a kind of immediate maintenance, in which materialized view= s are updated immediately after a base table is modified. =20 Source repository: [https://github.com/sraoss/pg_ivm](https://github.com/sr= aoss/pg_ivm) --===============1921304801497964898== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable pg_ivm 1.10 released
 

pg_ivm 1.10 released

IVM Development Group is pleased to announc= e the release of pg_ivm 1.10.=

Changes since the v1.9 release include:

Bug Fixes

  • Fix a failure in DROP EXTENSION (Ishant Bha= skar )

    Previously, dropping pg_ivm caused the erro= r "could not open relation with OID ..."=20 due to a hook function that allows DROP TABLE on an IMMV to remove its entry from pg_ivm_immv. Additionally, issuing DROP TABLE concurrently with DROP EXTENSION pg_ivm could result in the same error.

  • Prevent automatic index creation when using= set-returning function (Yugo Nagata)

    A unique index was previously created autom= atically even when a set-returning=20 function appeared in the FROM clause, which led to errors due to key duplic= ation.

  • Change schema from pg_catalog to pgivm (Yug= o Nagata)

    Previously, pg_upgrade failed due to permis= sion issues because the pg_ivm_immv=20 catalog was created in pg_catalog. To resolve this, all objects created by = pg_ivm have been moved to the pgivm schema, which is now created automatically by = pg_ivm.

    Breaking Change: This affects compatibility= with previous releases. If you want to access objects like the create_immv function as before, you must either qua= lify them with the pgivm schema or adjust your search_path accordingly.

  • Fixed view maintenance failures when a colu= mn is dropped from a table (Yugo Nagata)

    When a table contained a dropped column, in= cremental view maintenance failed with an error like:

    ERROR: could not find attribute 43 in= subquery targetlist

  • Fix potential view inconsistency issues (Yu= go Nagata)

    Previously, the view contents could become = inconsistent with the base tables in the following scenarios:

    1) A concurrent transaction modifies a base= table and commits before the incremental view maintenance starts in the current transaction.

    2) A concurrent transaction modifies a bas= e table and commits before the create_immv or refresh_immv command generates data.

    3) Concurrent transactions incrementally up= date a view with a self-join or modify multiple base tables simultaneously.

    These issues have now been resolved to ensu= re consistency.

About pg_ivm

pg_ivm is an extension module that provides= Incremental View Maintenance (IVM) feature.

Incremental View Maintenance (IVM) is a way= to make materialized views up-to-date in which only incremental changes are computed and applied on views rather tha= n recomputing.=20 pg_ivm provides a kind of immediate maintenance, in which materialized view= s are updated immediately after a base table is modified.

Source repository: h= ttps://github.com/sraoss/pg_ivm
This email was sent to you from IVM Development Group. It was delivered on = their behalf by the PostgreSQL project. Any questions about the content of the message shou= ld be sent to IVM Development Group.

You were sent this email as a subscriber of the pgsql-announce mai= linglist, for the content tag Related Open Source. To unsubscribe from further emails, or change which emails you want to receive, please click th= e personal unsubscribe link that you can find in the headers of this email, or visit https://lists.postgresql.org/unsubscribe/.
 
--===============1921304801497964898==-- --===============6296956721530049119==--