Re: Adding REPACK [concurrently] - Mailing list pgsql-hackers

From Mihail Nikalayeu
Subject Re: Adding REPACK [concurrently]
Date
Msg-id CADzfLwURy8_BYyqrvr6rhTXsW3=5QMRLHuNati3CgY0nKRSwyw@mail.gmail.com
Whole thread
In response to Re: Adding REPACK [concurrently]  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Adding REPACK [concurrently]
Re: Adding REPACK [concurrently]
Re: Adding REPACK [concurrently]
List 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



pgsql-hackers by date:

Previous
From: Greg Sabino Mullane
Date:
Subject: Re: Read-only connection mode for AI workflows.
Next
From: Marco Nenciarini
Date:
Subject: Re: BUG: Cascading standby fails to reconnect after falling back to archive recovery