Re: [WIP]Vertical Clustered Index (columnar store extension) - take2

On Tue, 22 Jul 2025 at 17:46, Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> Hi.
>
> Here are the latest v14 patches.
>
> Changes include:
>
> PATCH 0002.
> - Fixes the enable_seqscan PANIC bug reported by Japin [1]
> - Adds a new regression test case for this
>
> ======
> [1] https://www.postgresql.org/message-id/ME0P300MB04457E24CA8965F008FB2CDBB648A%40ME0P300MB0445.AUSP300.PROD.OUTLOOK.COM
>

Hi.

Thanks for updating the patchset.

1.
I encountered another crash while checking VCI's internal relations.

rm -rf demo
initdb -D demo
cat <<EOF >demo/postgresql.auto.conf
shared_preload_libraries = 'vci'
max_worker_processes = '20'
EOF

pg_ctl -D demo start

cat <<EOF | psql postgres
CREATE EXTENSION vci;
CREATE TABLE t (id int, info text);
CREATE INDEX ON t USING vci (id);
SELECT relname FROM pg_class WHERE relname ~ '^vci_*' LIMIT 1 \gset
SELECT * FROM :relname;
\d+ :relname
REFRESH MATERIALIZED VIEW :relname;
EOF

VCI's definition of internal relations as materialized views lacks the
corresponding view bodies.

+ /*
+ * @see
+ * https://www.postgresql.jp/document/9.4/html/catalog-pg-rewrite.html
+ */
+ new_rel_reltup->relhasrules = true;
+
+ new_rel->rd_att->tdtypeid = new_type_oid;
+
+ InsertPgClassTuple(pg_class, new_rel, new_oid, (Datum) 0, (Datum) 0);

Given that VCI's internal relations are materialized views, are VCI workers
responsible for their periodic refreshment?

Or is it by design that users are unable to read the internal relations?

2.
+#ifdef WIN32
+ char *dir_name = "base\\" PG_TEMP_FILES_DIR;
+#endif
+
+#ifdef __sparc__
+ char *dir_name = "base/" PG_TEMP_FILES_DIR;
+#endif

I think it's also possible to use the second format on Windows.
And what happens if neither WIN32 nor __sparc__ are defined?

--
Regards,
Japin Li