Hello, Antonin!
On Thu, Jan 8, 2026 at 7:59 PM Antonin Houska <[email protected]> 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.
