Re: Adding REPACK [concurrently]

Hello, Antonin!

On Thu, Jan 8, 2026 at 7:59 PM Antonin Houska <ah(at)cybertec(dot)at> wrote:
> v29 tries to fix the problem.

Some comments for 0001-0004.

------ 0001 -----

> src/bin/scripts/t/103_repackdb.pl:1:
> # Copyright (c) 2021-2025

Update year for 2026.

> * FIXME: this is missing a way to specify the index to use to repack one
> * table, or whether to pass a WITH INDEX clause when multiple tables are
> * used. Something like --index[=indexname]. Adding that bleeds into
> * vacuuming.c as well.

Comments look stale.

> return "???";
I think it is better to add Assert(false); before (done that way in a
few places).

> command <link linkend="sql-repack"><command>REPACK</command></link> There
need .

> “An utility”
Should be “A utility”

> else if (pg_strcasecmp(cmd, "CLUSTER") == 0)
> cmdtype = PROGRESS_COMMAND_CLUSTER;

Should we set PROGRESS_COMMAND_REPACK here? Because cluster is not
used anywhere. Probably we may even delete PROGRESS_COMMAND_CLUSTER.

> CLUOPT_RECHECK_ISCLUSTERED
It is not set anymore... Probably something is wrong here or we need
to just remove that constant and check for it.

------ 0002 -----

> rebuild_relation(Relation OldHeap, Relation index, bool verbose)
It removes unused cmd parameter, but I think it is better to not add
it in the previous commit.

------ 0003 -----

> int newxcnt = 0;

I think it is better to use uint32 for consistency here.

Also, I think it is worth adding Assert(snapshot->snapshot_type ==
SNAPSHOT_HISTORIC_MVCC)

------ 0004 -----

> /* Is REPACK (CONCURRENTLY) being run by this backend? */
> if (am_decoding_for_repack())

We should check change_useless_for_repack here - to avoid looking and
TRUNCATE of unrelated tables.

> /* For the same reason, unlock TOAST relation. */
> if (OldHeap->rd_rel->reltoastrelid)
> LockRelationOid(OldHeap->rd_rel->reltoastrelid, AccessExclusiveLock);

Hm, we are locking here instead of unlocking ;)

> (errhint("Relation \"%s\" has no identity index.",
> RelationGetRelationName(rel)))));

One level of braces may be removed.

> * to decode on behalf of REPACK (CONCURRENT)?

CONCURRENTLY

> * If recheck is required, it must have been preformed on the source

"performed"

> * On exit,'*scan_p' contains the scan descriptor used. The caller must close
> * it when he no longer needs the tuple returned.

There is no scan_p argument here.

> * Copyright (c) 2012-2025, PostgreSQL Global Development Group

2026

> newtuple = change->data.tp.newtuple != NULL ?
> change->data.tp.newtuple : NULL;

> oldtuple = change->data.tp.oldtuple != NULL ?
> change->data.tp.oldtuple : NULL;
> newtuple = change->data.tp.newtuple != NULL ?
> change->data.tp.newtuple : NULL;

Hm, should it be just x = y ?

> apply_concurrent_insert

Double newline at function start.

> heap2_decode

Should we check for change_useless_for_repack here also? (for multi
insert, for example).

Best regards,
Mikhail.