Fix wrong-result and crash bugs in summary build, maintenance and pruning (0.1.2)

.github/workflows/ci.yml

@@ -60,6 +60,15 @@ jobs:
       - name: Run tests
         run: cargo pgrx test ${{ matrix.pg }}
 
+      - name: Run multi-session tests
+        run: |
+          PG_CONFIG="$(cargo pgrx info pg-config ${{ matrix.pg }})"
+          MAJOR="${{ matrix.pg }}"; MAJOR="${MAJOR#pg}"
+          cargo pgrx install --no-default-features --features ${{ matrix.pg }} --pg-config "$PG_CONFIG"
+          cargo pgrx start ${{ matrix.pg }}
+          PATH="$(dirname "$PG_CONFIG"):$PATH" PGHOST=localhost PGPORT=$((28800 + MAJOR)) \
+            tests/multisession.sh
+
   postgis:
     name: postgis (pg16)
     runs-on: ubuntu-latest

CHANGELOG.md

@@ -0,0 +1,58 @@
+# Changelog
+
+## 0.1.2
+
+A correctness release. 0.1.1 could return wrong results (rows missing from query
+results) and could crash the server.
+
+Summaries built by 0.1.1 are not trusted: 0.1.2 never prunes with them, so each
+table_range index keeps all partitions (results correct, just unpruned) until it is
+rebuilt. To upgrade:
+
+1. Install 0.1.2 and **restart PostgreSQL**, so no backend still runs 0.1.1 code (a
+   0.1.1 backend cannot read 0.1.2 summaries and would skip widening them).
+2. `ALTER EXTENSION pg_table_range UPDATE;` (warns how many indexes need rebuilding).
+3. `REINDEX INDEX` each table_range index (on a partitioned table, the parent index).
+
+### Crashes fixed
+
+- Any error raised while planning a query (e.g. `SELECT 1/0`) in a backend that had
+  loaded the extension aborted the backend, restarting the whole cluster.
+- `REINDEX` of a table_range index crashed the server the same way.
+
+### Wrong results fixed
+
+- Prepared statements and PL/pgSQL functions kept using plans that pruned a partition
+  after an insert had widened its summary.
+- A second widening inside one transaction was invisible to that transaction's later
+  queries; after a rolled-back savepoint, a later widening was never seen by other
+  backends.
+- Concurrent inserts could overwrite each other's widening.
+- A widening that failed (e.g. a value too large for the metapage) was silently skipped.
+- Partial table_range indexes ignored inserts outside their predicate. They are now
+  rejected.
+- `CREATE INDEX` inside a `REPEATABLE READ` transaction missed rows committed after the
+  transaction's snapshot, and builds omitted rows still visible to older snapshots.
+- Summary bounds depended on `DateStyle` and `extra_float_digits` at write and read time.
+- Cross-type comparisons (e.g. `float8_col > 1.5::float4`) re-parsed the constant as the
+  column's type.
+- Comparisons under a different collation than the summary's (e.g. `COLLATE "C"` on an
+  `en_US` column) were pruned with the wrong ordering.
+
+### Other fixes
+
+- `CREATE INDEX` / `REINDEX` set the table's `reltuples` to 0, so the planner estimated
+  one row per partition until the next `ANALYZE`.
+- Indexes including a `uuid` or `boolean` column silently built no summary at all (those
+  types have no `min()`/`max()`). Builds no longer use SQL aggregates.
+- On PostgreSQL 17+, geometry summaries could not be built (index builds run with a
+  restricted `search_path`). All SQL the extension runs is now schema-qualified, which
+  also stops a caller's `search_path` from substituting functions used to maintain
+  summaries.
+- Updates that change only table_range-indexed columns can be HOT updates again
+  (`amsummarizing`).
+- The README no longer claims `VACUUM` re-tightens summaries; `REINDEX` does.
+
+### Format
+
+Summaries are stored in on-page format version 2. Version-1 summaries are ignored.

Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "pg_table_range"
-version = "0.1.1"
+version = "0.1.2"
 edition = "2021"
 license = "MIT"
 description = "PostgreSQL extension for planning-time partition pruning by per-partition data ranges, including non-key columns."

META.json

@@ -2,7 +2,7 @@
    "name": "pg_table_range",
    "abstract": "Planning-time partition pruning by per-partition data ranges, including non-key columns",
    "description": "pg_table_range prunes partitions at planning time from a compact per-partition summary of each column's actual data: its min/max range for btree-comparable scalar types, or a covering extent for range types and PostGIS geometry. Unlike native PostgreSQL partition pruning, it works on columns that are not the partition key. Summaries are stored in the index's own metapage and maintained incrementally on insert (like BRIN), so no REINDEX is needed, and pruning is conservative so results are always identical to running without it.",
-   "version": "0.1.1",
+   "version": "0.1.2",
    "maintainer": [
       "David Bitner <bitner@dbspatial.com>"
    ],
@@ -12,7 +12,7 @@
          "abstract": "Planning-time partition pruning by per-partition data ranges, including non-key columns",
          "file": "pg_table_range.control",
          "docfile": "README.md",
-         "version": "0.1.1"
+         "version": "0.1.2"
       }
    },
    "prereqs": {