Re: Adding REPACK [concurrently]

From: Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Antonin Houska <ah(at)cybertec(dot)at>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net>
Subject: Re: Adding REPACK [concurrently]
Date: 2026-03-20 12:35:00
Message-ID: CADzfLwURy8_BYyqrvr6rhTXsW3=5QMRLHuNati3CgY0nKRSwyw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hello, everyone!

Some comments for v43:

---
src/backend/commands/cluster.c:3211

slot_attisnull(dest, i) uses a 0-based loop index but slot_attisnull
starts with "Assert(attnum > 0);".
Also, it proves it has not been tested in any way yet.

------------------------------

src/backend/storage/ipc/standby.c:1376

"if (xlrec.xcnt > 0)"
looks like it should be "xlrec.xcnt + xlrec.xcnt_repack > 0" because
of "CurrentRunningXacts->xcnt = count - subcount - count_repack;"

------------------------------

src/backend/storage/ipc/procarray.c:2673-2681

"nrepack = logical_decoding_enabled ? MAX_REPACK_XIDS : 0"
not sure it is a real issue, but if EnableLogicalDecoding is called
somehow after allocating the array - it makes it possible to overrun
the array later by MAX_REPACK_XIDS.

------------------------------

src/backend/commands/cluster.c:3006

"apply_cxt = AllocSetContextCreate(TopTransactionContext,
"REPACK - apply",
ALLOCSET_DEFAULT_SIZES);"

Should we do it before the "MakeSingleTupleTableSlot" calls?
Because MakeSingleTupleTableSlot stored CurrentMemoryContext in tts_mcxt.

------------------------------

src/backend/commands/cluster.c:3187

if (natt_ext != 0)
elog(WARNING, "have natt_ext %d, weird", natt_ext);

Should we make that ERROR?

------------------------------

src/backend/access/rmgrdesc/standbydesc.c:24

appendStringInfo(buf, "nextXid %u latestCompletedXid %u
oldestRunningXid %u oldestRunningXid %u",

"oldestRunningXidLogical" at the end?

------------------------------

src/backend/catalog/index.c:766,1464-1469

"bool progress = (flags & INDEX_CREATE_REPORT_PROGRESS) != 0;"

AFAIU gin, hash and btree (at least) still just unconditionally write
PROGRESS_CREATEIDX_* progress.
------------------------------

src/backend/catalog/toasting.c:334

"INDEX_CREATE_IS_PRIMARY | INDEX_CREATE_REPORT_PROGRESS, 0,"

Should we add the "progress" flag too here and move it from make_new_heap?

-------------------------------

Also just, gently remind you about [1] and a simple way to avoid any
unnoticed MVCC-related issues with REPACK proposed here [2].

Best regards,
Mikhail.

[1]: https://www.postgresql.org/message-id/flat/5k2dfckyp6zv2fiovosvtbya5onvplgviz5n4kdamxupff4vi2%40yytzfnwr2ox7#c52bec0a074779921b14c1e46da9ed21
[2]: https://www.postgresql.org/message-id/CADzfLwUEH5+LjCN+6kRfSsXwuou8rKXyVV42Wi-O_TG0360Kug@mail.gmail.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marco Nenciarini 2026-03-20 12:40:42 Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery
Previous Message Greg Sabino Mullane 2026-03-20 12:32:24 Re: Read-only connection mode for AI workflows.