Re: Adding REPACK [concurrently]

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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