Horton

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

Japin Li <japinli@hotmail.com>

View thread
From: Japin Li <japinli@hotmail.com>
To: Peter Smith <smithpb2250@gmail.com>
Cc: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Tomas Vondra <tomas@vondra.me>, "Aya Iwata (Fujitsu)" <iwata.aya@fujitsu.com>, Timur Magomedov <t.magomedov@postgrespro.ru>, shveta malik <shveta.malik@gmail.com>
Date: 2025-07-31T08:20:00Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Mark ItemPointer arguments as const throughout

  2. Reorganize GUC structs

  3. Eliminate XLOG_HEAP2_VISIBLE from vacuum phase III

  4. Update various forward declarations to use typedef

  5. Pathify RHS unique-ification for semijoin planning

  6. Revert "Don't lock partitions pruned by initial pruning"

  7. For inplace update, send nontransactional invalidations.

  8. Remove nearly-unused SizeOfIptrData macro.

Attachments

On Wed, 30 Jul 2025 at 19:07, Japin Li <japinli@hotmail.com> wrote:
> On Tue, 29 Jul 2025 at 06:57, Peter Smith <smithpb2250@gmail.com> wrote:
>> Here are the latest v15 patches.
>>
>> Changes include:
>>
>> PATCH 0002.
>> - README now says user should not tamper with VCI internal relations
>> - fixes/test the VACUUM bug -- fix provided by Japin [1]
>> - fixes/tests the reported segv for attempted REFRESH of VCI internal
>> relation -- see [2 comment#1]
>> - fixes/tests VCI internal relation dependency on the indexed table
>> - simplifies code for PG_TEMP_FILES_DIR -- see [2 comment#2]
>>
>
> Hi Peter,
>
> Thanks for updating the patches.
>
> 1.
> I've identified another TRAP failure. Here are the reproduction steps:
>
> 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);
> INSERT INTO t SELECT id, md5(random()::text) FROM generate_series(1, 1000) id;
> REINDEX TABLE t;
> REINDEX TABLE t;
> EOF
>
> The current VCI design doesn't support REINDEX, which is expected. But I've
> discovered an unexpected issue: running REINDEX on a table a second time causes
> an assertion failure.
>

It appears VCI doesn't support reindexing; add_reindex_index_hook() returns
false, and reindex_index() exits without restoring the security context.

PFA.

-- 
Regards,
Japin Li
ChengDu WenWu Information Technology Co., Ltd.