luciano/pg_ivm
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
pg_ivm/Makefile

31 lines
857 B
Makefile
Raw Normal View History

Initial release of pg_ivm 1.0
2022-03-31 12:48:53 +00:00
# contrib/pg_ivm/Makefile
Split files to make it easier to follow the core code
2022-04-27 05:45:47 +00:00
MODULE_big = pg_ivm
OBJS = \
$(WIN32RES) \
createas.o \
matview.o \
Support min/max aggregates (#18) In order to re-calculate min/max values for groups where the min or max value is deleted, we need the view query definition in string form. However, pg_get_viewdef cannot be used for this purpose because IMMV's defenition is in pg_ivm_immv but not pg_rewrite. Therefore, we have to convert query definition in pg_ivm_immv to query definition string. We can use pg_get_querydef in PG15, but we cannot in PG14 or earlier, so we use codes in ruleutil.c copied from PG13 or PG14 depending versions.
2022-07-25 04:11:33 +00:00
pg_ivm.o \
Add CTE support (#47) Simple CTEs which does not contain aggregates or DISTINCT are now supported similarly to simple sub-queries. Before a view is maintained, all CTEs are converted to corresponding subqueries to enable to treat CTEs as same as subqueries. For this end, codes of the static function inline_cte in the core (optimizer/plan/subselect.c) was imported. Prohibit Unreferenced CTE is prohibited. When a table in a unreferenced CTE is TRUNCATEd, the contents of the IMMV is not affected so it must not be truncated. For confirming it at the maintenance time, we have to check if the modified table used in a CTE is actually referenced. Although it would possible, we just disallow to create such IMMVs for now since such unreferenced CTE is useless unless it doesn't contain modifying commands, that is already prohibited.
2023-01-30 02:28:27 +00:00
ruleutils.o \
subselect.o
Split files to make it easier to follow the core code
2022-04-27 05:45:47 +00:00
PGFILEDESC = "pg_ivm - incremental view maintenance on PostgreSQL"
Initial release of pg_ivm 1.0
2022-03-31 12:48:53 +00:00
EXTENSION = pg_ivm
Fix Makefile to install pg_ivm--1.3--1.4.sql (#45) This should have be included in the previous commit but was accidentally forgotten. Issue #43
2023-01-10 09:41:50 +00:00
DATA = pg_ivm--1.0.sql \
pg_ivm--1.0--1.1.sql pg_ivm--1.1--1.2.sql pg_ivm--1.2--1.3.sql \
Prepare 1.7
2023-09-13 02:13:40 +00:00
pg_ivm--1.3--1.4.sql pg_ivm--1.4--1.5.sql pg_ivm--1.5--1.6.sql \
Bump up to 1.10
2024-12-09 11:01:46 +00:00
pg_ivm--1.6--1.7.sql pg_ivm--1.7--1.8.sql pg_ivm--1.8--1.9.sql \
Change the schema from pg_catalog to pgivm (#116) Previously, pg_upgrade failed due to the permission denied because the pg_ivm_immv catalog was in the pg_catalog catalog (Issue #79). To fix this, all objects created by pg_ivm are moved to theschema pgivm, which is also created by pg_ivm. pg_ivm is still not relocatable and this must be installed to the pgivm schema because the catalog and some internal functions are referred to unqualified by the schema name from the pg_ivm module. In future, this might be able to relocatable during installation, though. This commit affects compatibility with previous releases. To allow to access objects like create_immv function as previous, you need to qualify them with the schema name or setup search_path properly.
2025-02-17 03:07:21 +00:00
pg_ivm--1.9--1.10.sql \
pg_ivm--1.10.sql
Initial release of pg_ivm 1.0
2022-03-31 12:48:53 +00:00
Add refresh_immv() function refresh_immv(immv_name, with_data) is a function to refresh IMMV like REFRESH MATERIALIZED VIEW command. It has two argument. immv_name is incrementally maintainable materialized view's name, and with_data is an option that is corresponding to the WITH [NO] DATA option. When with_data is set false, the IMMV gets unpopulated. One of differences between IMMVs unpopulated by this function and normal materialized views unpopulated by REFRESH ... WITH NO DATA is that such IMMVs can be referenced by SELECT but return no rows, while unpopulated materialized views are not scanable. The behaviour may be changed in future to raise an error when unpopulated an IMMV is scanned.
2022-06-13 09:22:28 +00:00
REGRESS = pg_ivm create_immv refresh_immv
Initial release of pg_ivm 1.0
2022-03-31 12:48:53 +00:00
Fix potential view inconsistency issues (#121) 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 base table and commits before the 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. Incremental updates of a view are generally performed sequentially using an exclusive lock. However, even if we are able to acquire the lock, a concurrent transaction may have already incrementally updated the view and been committed before we can acquire it. In REPEATABLE READ or SERIALIZABLE isolation levels, this could lead to an inconsistent view state, which is the cause of the first issue. To fix this, a new field, lastivmupdate, has been added to the pg_ivm_immv catalog to record the transaction ID of the most recent update to the view. Before performing view maintenance, the transaction ID is checked. If the transaction was still in progress at the start of the current transaction, an error is raised to prevent anomalies. To fix the second issue, the timing of CreateTrigger() has been moved to before data generation. This ensures that locks conflicting with table modifications have been acquired on all base tables. In addition, the latest snapshot is used in READ COMMITTED level during the data generation to reflect committed changes from concurrent transactions. Additionally, inconsistencies that cannot be avoided through locking are prevented by checking the transaction ID of the last view update, as done for the first issue. However, concurrent table modifications and create_immv execution still cannot be detected at the time of view creation. Therefore, create_immv raises a warning in REPEATABLE READ or SERIALIZABLE isolation levels, suggesting that the command be used in READ COMMITTED mode or that refresh_immv be executed afterward to ensure the view remains consistent. The third issue was caused by the snapshot used for checking tuple visibility in the table's pre-update state not being the latest one. To fix this, the latest snapshot is now used in READ COMMITTED mode. Isolation tests are also added. Issue #104
2025-03-10 09:26:54 +00:00
ISOLATION = create_insert refresh_insert insert_insert \
create_insert2 refresh_insert2 insert_insert2 \
create_insert3 refresh_insert3 insert_insert3
ISOLATION_OPTS = --load-extension=pg_ivm
Allow to variable PG_CONFIG together with make command
2022-11-25 09:33:27 +00:00
PG_CONFIG ?= pg_config
Initial release of pg_ivm 1.0
2022-03-31 12:48:53 +00:00
PGXS := $(shell $(PG_CONFIG) --pgxs)
include $(PGXS)
Reference in a new issue Copy permalink