Horton
Menu

Re: Adding REPACK [concurrently]

Antonin Houska <ah@cybertec.at>

View thread
From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Mihail Nikalayeu <mihailnikalayeu@gmail.com>, Pg Hackers <pgsql-hackers@lists.postgresql.org>, Robert Treat <rob@xzilla.net>
Date: 2026-03-11T15:54:22Z
Lists: pgsql-hackers

Attachments

Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:

> I have just pushed 0001 with some additional changes.

Thanks!

> Here's a rebase of the next ones; no changes other than fixing the
> conflicts.
> 
> I'm seeing this warning caused by 0004, which I think is also being
> reported in CI
> https://cirrus-ci.com/task/6606871575920640
> 
> [281/1134] Compiling C object src/backend/postgres_lib.a.p/commands_cluster.c.o
> In file included from ../../source/repack/src/include/access/htup_details.h:22,
>                  from ../../source/repack/src/include/access/relscan.h:17,
>                  from ../../source/repack/src/include/access/heapam.h:19,
>                  from ../../source/repack/src/backend/commands/cluster.c:37:
> In function ‘VARSIZE_ANY’,
>     inlined from ‘restore_tuple’ at ../../source/repack/src/backend/commands/cluster.c:3129:18,
>     inlined from ‘apply_concurrent_changes’ at ../../source/repack/src/backend/commands/cluster.c:2915:9,
>     inlined from ‘process_concurrent_changes’ at ../../source/repack/src/backend/commands/cluster.c:3386:2:
> ../../source/repack/src/include/varatt.h:243:51: warning: array subscript ‘varattrib_4b[0]’ is partly outside array bounds of ‘varlena[1]’ [-Warray-bounds=]
>   243 |         ((((const varattrib_4b *) (PTR))->va_4byte.va_header >> 2) & 0x3FFFFFFF)
>       |           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~
> ../../source/repack/src/include/varatt.h:467:24: note: in expansion of macro ‘VARSIZE_4B’
>   467 |                 return VARSIZE_4B(PTR);
>       |                        ^~~~~~~~~~
> ../../source/repack/src/backend/commands/cluster.c: In function ‘process_concurrent_changes’:
> ../../source/repack/src/backend/commands/cluster.c:3121:33: note: object ‘varhdr’ of size 4
>  3121 |                 varlena         varhdr;
>       |                                 ^~~~~~

I'm not sure it can be fixed nicely in the REPACK (CONCURRENTLY) patch. I
think the problem is that, in the current tree, VARSIZE_ANY() is used in such
a way that the compiler cannot check the "array bounds". The restore_tuple()
function is special in that it uses VARSIZE_ANY() to check a variable
allocated from the stack, so the compiler can check the size.

I'm trying to fix that in a new diff 0002 - the point is that VARSIZE_ANY()
should not need to dereference a pointer to varattrib_4b, since the size
information is always located at the beginning of the structure. Maybe you
have better idea.


Besides that, I've done a related change in 0003 (now 0004, due to the new
diff):

diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c
index 77e301b7c63..8b5571374d0 100644
--- a/src/backend/commands/cluster.c
+++ b/src/backend/commands/cluster.c
@@ -3118,7 +3118,7 @@ restore_tuple(BufFile *file, Relation relation, MemoryContext cxt)
 	BufFileReadExact(file, &natt_ext, sizeof(natt_ext));
 	for (int i = 0; i < natt_ext; i++)
 	{
-		varlena		varhdr;
+		alignas(uint32) varlena		varhdr;
 		char	   *ext_val;
 		Size		ext_val_size;
 


And also this one in the same file, to suppress another compiler warning
(occuring when configured w/o --enable-cassert):

diff --git a/src/backend/replication/pgoutput_repack/pgoutput_repack.c b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
index 707940c1127..90f3a8975b9 100644
--- a/src/backend/replication/pgoutput_repack/pgoutput_repack.c
+++ b/src/backend/replication/pgoutput_repack/pgoutput_repack.c
@@ -93,12 +93,9 @@ static void
 plugin_change(LogicalDecodingContext *ctx, ReorderBufferTXN *txn,
 			  Relation relation, ReorderBufferChange *change)
 {
-	RepackDecodingState *dstate;
-
-	dstate = (RepackDecodingState *) ctx->output_writer_private;
-
 	/* Changes of other relation should not have been decoded. */
-	Assert(RelationGetRelid(relation) == dstate->relid);
+	Assert(RelationGetRelid(relation) ==
+		   ((RepackDecodingState *) ctx->output_writer_private)->relid);
 
 	/* Decode entry depending on its type */
 	switch (change->action)


-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com

Commits

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

  1. Allow old WAL recycling during REPACK CONCURRENTLY

  2. Advance restart_lsn more eagerly in LogicalConfirmReceivedLocation

  3. Remove unnecessary signal handler change

  4. Improve REPACK (CONCURRENTLY) error messages some more

  5. Revert "Allow logical replication snapshots to be database-specific"

  6. Move REPACK (CONCURRENTLY) test out of stock regression tests

  7. REPACK: do not require REPLICATION or LOGIN

  8. Add missing initialization

  9. Simplify declaration of memcpy target

  10. Reserve replication slots specifically for REPACK

  11. doc: Add an example of REPACK (CONCURRENTLY)

  12. Allow logical replication snapshots to be database-specific

  13. Avoid different-size pointer-to-integer cast

  14. Fix valgrind failure

  15. Add CONCURRENTLY option to REPACK

  16. Rename cluster.c to repack.c (and corresponding .h)

  17. Allow index_create to suppress index_build progress reporting

  18. Make index_concurrently_create_copy more general

  19. Document the 'command' column of pg_stat_progress_repack

  20. Introduce the REPACK command

  21. Toggle logical decoding dynamically based on logical slot presence.

  22. Split vacuumdb to create vacuuming.c/h

  23. Remove ReorderBufferTupleBuf structure.

  24. Revert changes to CONCURRENTLY that "sped up" Xmin advance

  25. VACUUM: ignore indexing operations with CONCURRENTLY