agora inbox for [email protected]help / color / mirror / Atom feed
[PATCH] Remove useless "return;" lines 139+ messages / 2 participants [nested] [flat]
* [PATCH] Remove useless "return;" lines @ 2019-11-27 13:28 Alvaro Herrera <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Alvaro Herrera @ 2019-11-27 13:28 UTC (permalink / raw) --- src/backend/access/gist/gist.c | 2 -- src/backend/access/rmgrdesc/genericdesc.c | 2 -- src/backend/access/transam/twophase.c | 2 -- src/backend/access/transam/xact.c | 1 - src/backend/executor/nodeTableFuncscan.c | 2 -- src/backend/jit/llvm/llvmjit.c | 2 -- src/backend/libpq/hba.c | 1 - src/backend/replication/logical/launcher.c | 2 -- src/backend/replication/walsender.c | 3 --- src/backend/rewrite/rowsecurity.c | 2 -- src/backend/utils/adt/datetime.c | 2 -- src/bin/pg_ctl/pg_ctl.c | 2 -- src/bin/pg_dump/compress_io.c | 4 ---- src/bin/pg_dump/pg_backup_archiver.c | 5 ----- src/bin/pg_dump/pg_backup_custom.c | 7 ------- src/bin/pg_dump/pg_backup_directory.c | 7 ------- src/bin/pg_dump/pg_backup_null.c | 3 --- src/bin/pg_dump/pg_backup_tar.c | 3 --- src/bin/pg_dump/pg_dump.c | 2 -- src/bin/pg_upgrade/parallel.c | 4 ---- src/bin/pg_upgrade/relfilenode.c | 4 ---- src/bin/pg_upgrade/tablespace.c | 2 -- src/bin/psql/common.c | 2 -- src/fe_utils/print.c | 2 -- src/interfaces/ecpg/compatlib/informix.c | 2 -- src/interfaces/ecpg/pgtypeslib/datetime.c | 1 - src/interfaces/ecpg/pgtypeslib/dt_common.c | 2 -- src/interfaces/ecpg/pgtypeslib/timestamp.c | 1 - src/interfaces/libpq/fe-auth-scram.c | 1 - src/pl/plperl/plperl.c | 4 ---- src/pl/plpgsql/src/pl_exec.c | 2 -- src/port/win32error.c | 1 - 32 files changed, 82 deletions(-) diff --git a/src/backend/access/gist/gist.c b/src/backend/access/gist/gist.c index 8d9c8d025d..3800f58ce7 100644 --- a/src/backend/access/gist/gist.c +++ b/src/backend/access/gist/gist.c @@ -1088,8 +1088,6 @@ gistFindCorrectParent(Relation r, GISTInsertStack *child) LockBuffer(child->parent->buffer, GIST_EXCLUSIVE); gistFindCorrectParent(r, child); } - - return; } /* diff --git a/src/backend/access/rmgrdesc/genericdesc.c b/src/backend/access/rmgrdesc/genericdesc.c index 0fe02dc85a..3bad0578eb 100644 --- a/src/backend/access/rmgrdesc/genericdesc.c +++ b/src/backend/access/rmgrdesc/genericdesc.c @@ -43,8 +43,6 @@ generic_desc(StringInfo buf, XLogReaderState *record) else appendStringInfo(buf, "offset %u, length %u", offset, length); } - - return; } /* diff --git a/src/backend/access/transam/twophase.c b/src/backend/access/transam/twophase.c index b3ad0d08e3..529976885f 100644 --- a/src/backend/access/transam/twophase.c +++ b/src/backend/access/transam/twophase.c @@ -2436,6 +2436,4 @@ PrepareRedoRemove(TransactionId xid, bool giveWarning) if (gxact->ondisk) RemoveTwoPhaseFile(xid, giveWarning); RemoveGXact(gxact); - - return; } diff --git a/src/backend/access/transam/xact.c b/src/backend/access/transam/xact.c index 5c0d0f2af0..5353b6ab0b 100644 --- a/src/backend/access/transam/xact.c +++ b/src/backend/access/transam/xact.c @@ -3428,7 +3428,6 @@ CheckTransactionBlock(bool isTopLevel, bool throwError, const char *stmtType) /* translator: %s represents an SQL statement name */ errmsg("%s can only be used in transaction blocks", stmtType))); - return; } /* diff --git a/src/backend/executor/nodeTableFuncscan.c b/src/backend/executor/nodeTableFuncscan.c index 21cf3ca0c9..ffcf4613f4 100644 --- a/src/backend/executor/nodeTableFuncscan.c +++ b/src/backend/executor/nodeTableFuncscan.c @@ -335,8 +335,6 @@ tfuncFetchRows(TableFuncScanState *tstate, ExprContext *econtext) MemoryContextSwitchTo(oldcxt); MemoryContextReset(tstate->perTableCxt); - - return; } /* diff --git a/src/backend/jit/llvm/llvmjit.c b/src/backend/jit/llvm/llvmjit.c index 1c851e00fc..3b52d8cc21 100644 --- a/src/backend/jit/llvm/llvmjit.c +++ b/src/backend/jit/llvm/llvmjit.c @@ -834,8 +834,6 @@ llvm_create_types(void) * Leave the module alive, otherwise references to function would be * dangling. */ - - return; } /* diff --git a/src/backend/libpq/hba.c b/src/backend/libpq/hba.c index cc4b661433..9989904769 100644 --- a/src/backend/libpq/hba.c +++ b/src/backend/libpq/hba.c @@ -2903,7 +2903,6 @@ check_ident_usermap(IdentLine *identLine, const char *usermap_name, *found_p = true; } } - return; } diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c index 1f8821cc43..4643af95fe 100644 --- a/src/backend/replication/logical/launcher.c +++ b/src/backend/replication/logical/launcher.c @@ -223,8 +223,6 @@ WaitForReplicationWorkerAttach(LogicalRepWorker *worker, CHECK_FOR_INTERRUPTS(); } } - - return; } /* diff --git a/src/backend/replication/walsender.c b/src/backend/replication/walsender.c index ac9209747a..8bafa65e50 100644 --- a/src/backend/replication/walsender.c +++ b/src/backend/replication/walsender.c @@ -2301,7 +2301,6 @@ WalSndLoop(WalSndSendDataCallback send_data) WAIT_EVENT_WAL_SENDER_MAIN); } } - return; } /* Initialize a per-walsender data structure for this walsender process */ @@ -2757,8 +2756,6 @@ retry: (uint32) (sentPtr >> 32), (uint32) sentPtr); set_ps_display(activitymsg, false); } - - return; } /* diff --git a/src/backend/rewrite/rowsecurity.c b/src/backend/rewrite/rowsecurity.c index df7bde380d..1969d53a11 100644 --- a/src/backend/rewrite/rowsecurity.c +++ b/src/backend/rewrite/rowsecurity.c @@ -394,8 +394,6 @@ get_row_security_policies(Query *root, RangeTblEntry *rte, int rt_index, * when necessary (eg: role changes) */ *hasRowSecurity = true; - - return; } /* diff --git a/src/backend/utils/adt/datetime.c b/src/backend/utils/adt/datetime.c index c911d7223c..b6ac90c051 100644 --- a/src/backend/utils/adt/datetime.c +++ b/src/backend/utils/adt/datetime.c @@ -313,8 +313,6 @@ j2date(int jd, int *year, int *month, int *day) quad = julian * 2141 / 65536; *day = julian - 7834 * quad / 256; *month = (quad + 10) % MONTHS_PER_YEAR + 1; - - return; } /* j2date() */ diff --git a/src/bin/pg_ctl/pg_ctl.c b/src/bin/pg_ctl/pg_ctl.c index 95e5fafe1f..65f9fb4c0a 100644 --- a/src/bin/pg_ctl/pg_ctl.c +++ b/src/bin/pg_ctl/pg_ctl.c @@ -422,8 +422,6 @@ free_readfile(char **optlines) free(curr_line); free(optlines); - - return; } /* diff --git a/src/bin/pg_dump/compress_io.c b/src/bin/pg_dump/compress_io.c index 03c3e73ad0..b2ca565494 100644 --- a/src/bin/pg_dump/compress_io.c +++ b/src/bin/pg_dump/compress_io.c @@ -192,7 +192,6 @@ WriteDataToArchive(ArchiveHandle *AH, CompressorState *cs, WriteDataToArchiveNone(AH, cs, data, dLen); break; } - return; } /* @@ -308,8 +307,6 @@ WriteDataToArchiveZlib(ArchiveHandle *AH, CompressorState *cs, cs->zp->next_in = (void *) unconstify(char *, data); cs->zp->avail_in = dLen; DeflateCompressorZlib(AH, cs, false); - - return; } static void @@ -407,7 +404,6 @@ WriteDataToArchiveNone(ArchiveHandle *AH, CompressorState *cs, const char *data, size_t dLen) { cs->writeF(AH, data, dLen); - return; } diff --git a/src/bin/pg_dump/pg_backup_archiver.c b/src/bin/pg_dump/pg_backup_archiver.c index d051f267ba..77bf9edaba 100644 --- a/src/bin/pg_dump/pg_backup_archiver.c +++ b/src/bin/pg_dump/pg_backup_archiver.c @@ -1045,8 +1045,6 @@ WriteData(Archive *AHX, const void *data, size_t dLen) fatal("internal error -- WriteData cannot be called outside the context of a DataDumper routine"); AH->WriteDataPtr(AH, data, dLen); - - return; } /* @@ -1461,7 +1459,6 @@ void archputs(const char *s, Archive *AH) { WriteData(AH, s, strlen(s)); - return; } /* Public */ @@ -1736,8 +1733,6 @@ ahwrite(const void *ptr, size_t size, size_t nmemb, ArchiveHandle *AH) if (bytes_written != size * nmemb) WRITE_ERROR_EXIT; - - return; } /* on some error, we may decide to go on... */ diff --git a/src/bin/pg_dump/pg_backup_custom.c b/src/bin/pg_dump/pg_backup_custom.c index fc742f5b56..369dcea429 100644 --- a/src/bin/pg_dump/pg_backup_custom.c +++ b/src/bin/pg_dump/pg_backup_custom.c @@ -317,8 +317,6 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t dLen) if (dLen > 0) /* WriteDataToArchive() internally throws write errors */ WriteDataToArchive(AH, cs, data, dLen); - - return; } /* @@ -644,8 +642,6 @@ _WriteBuf(ArchiveHandle *AH, const void *buf, size_t len) if (fwrite(buf, 1, len, AH->FH) != len) WRITE_ERROR_EXIT; ctx->filePos += len; - - return; } /* @@ -663,8 +659,6 @@ _ReadBuf(ArchiveHandle *AH, void *buf, size_t len) if (fread(buf, 1, len, AH->FH) != len) READ_ERROR_EXIT(AH->FH); ctx->filePos += len; - - return; } /* @@ -945,7 +939,6 @@ _CustomWriteFunc(ArchiveHandle *AH, const char *buf, size_t len) WriteInt(AH, len); _WriteBuf(AH, buf, len); } - return; } /* diff --git a/src/bin/pg_dump/pg_backup_directory.c b/src/bin/pg_dump/pg_backup_directory.c index aa00bcaaff..8631abb43a 100644 --- a/src/bin/pg_dump/pg_backup_directory.c +++ b/src/bin/pg_dump/pg_backup_directory.c @@ -349,9 +349,6 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t dLen) if (dLen > 0 && cfwrite(data, dLen, ctx->dataFH) != dLen) fatal("could not write to output file: %s", get_cfp_error(ctx->dataFH)); - - - return; } /* @@ -517,8 +514,6 @@ _WriteBuf(ArchiveHandle *AH, const void *buf, size_t len) if (cfwrite(buf, len, ctx->dataFH) != len) fatal("could not write to output file: %s", get_cfp_error(ctx->dataFH)); - - return; } /* @@ -537,8 +532,6 @@ _ReadBuf(ArchiveHandle *AH, void *buf, size_t len) */ if (cfread(buf, len, ctx->dataFH) != len) fatal("could not read from input file: end of file"); - - return; } /* diff --git a/src/bin/pg_dump/pg_backup_null.c b/src/bin/pg_dump/pg_backup_null.c index c62f9436aa..0458979f3c 100644 --- a/src/bin/pg_dump/pg_backup_null.c +++ b/src/bin/pg_dump/pg_backup_null.c @@ -86,7 +86,6 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t dLen) { /* Just send it to output, ahwrite() already errors on failure */ ahwrite(data, 1, dLen, AH); - return; } /* @@ -109,7 +108,6 @@ _WriteBlobData(ArchiveHandle *AH, const void *data, size_t dLen) destroyPQExpBuffer(buf); } - return; } static void @@ -221,7 +219,6 @@ static void _WriteBuf(ArchiveHandle *AH, const void *buf, size_t len) { /* Don't do anything */ - return; } static void diff --git a/src/bin/pg_dump/pg_backup_tar.c b/src/bin/pg_dump/pg_backup_tar.c index fd74835165..775118f297 100644 --- a/src/bin/pg_dump/pg_backup_tar.c +++ b/src/bin/pg_dump/pg_backup_tar.c @@ -615,8 +615,6 @@ _WriteData(ArchiveHandle *AH, const void *data, size_t dLen) if (tarWrite(data, dLen, tctx->TH) != dLen) WRITE_ERROR_EXIT; - - return; } static void @@ -818,7 +816,6 @@ _ReadBuf(ArchiveHandle *AH, void *buf, size_t len) fatal("could not read from input file: end of file"); ctx->filePos += len; - return; } static void diff --git a/src/bin/pg_dump/pg_dump.c b/src/bin/pg_dump/pg_dump.c index bf69adc2f4..08658c8e86 100644 --- a/src/bin/pg_dump/pg_dump.c +++ b/src/bin/pg_dump/pg_dump.c @@ -15416,8 +15416,6 @@ dumpTable(Archive *fout, TableInfo *tbinfo) } free(namecopy); - - return; } /* diff --git a/src/bin/pg_upgrade/parallel.c b/src/bin/pg_upgrade/parallel.c index 39c508e73b..22fc7e5e0f 100644 --- a/src/bin/pg_upgrade/parallel.c +++ b/src/bin/pg_upgrade/parallel.c @@ -148,8 +148,6 @@ parallel_exec_prog(const char *log_file, const char *opt_log_file, thread_handles[parallel_jobs - 1] = child; #endif } - - return; } @@ -263,8 +261,6 @@ parallel_transfer_all_new_dbs(DbInfoArr *old_db_arr, DbInfoArr *new_db_arr, thread_handles[parallel_jobs - 1] = child; #endif } - - return; } diff --git a/src/bin/pg_upgrade/relfilenode.c b/src/bin/pg_upgrade/relfilenode.c index f9d0812cc5..9e6013bff1 100644 --- a/src/bin/pg_upgrade/relfilenode.c +++ b/src/bin/pg_upgrade/relfilenode.c @@ -73,8 +73,6 @@ transfer_all_new_tablespaces(DbInfoArr *old_db_arr, DbInfoArr *new_db_arr, end_progress_output(); check_ok(); - - return; } @@ -128,8 +126,6 @@ transfer_all_new_dbs(DbInfoArr *old_db_arr, DbInfoArr *new_db_arr, /* We allocate something even for n_maps == 0 */ pg_free(mappings); } - - return; } /* diff --git a/src/bin/pg_upgrade/tablespace.c b/src/bin/pg_upgrade/tablespace.c index dfe5bfdcfd..7f42d1e3c9 100644 --- a/src/bin/pg_upgrade/tablespace.c +++ b/src/bin/pg_upgrade/tablespace.c @@ -100,8 +100,6 @@ get_tablespace_paths(void) PQclear(res); PQfinish(conn); - - return; } diff --git a/src/bin/psql/common.c b/src/bin/psql/common.c index 90f6380170..53a1ea2bdb 100644 --- a/src/bin/psql/common.c +++ b/src/bin/psql/common.c @@ -2399,8 +2399,6 @@ expand_tilde(char **filename) } } #endif - - return; } /* diff --git a/src/fe_utils/print.c b/src/fe_utils/print.c index 1f8bde8443..b9cd6a1752 100644 --- a/src/fe_utils/print.c +++ b/src/fe_utils/print.c @@ -3619,8 +3619,6 @@ refresh_utf8format(const printTableOpt *opt) popt->wrap_left = unicode_style.wrap_left; popt->wrap_right = unicode_style.wrap_right; popt->wrap_right_border = unicode_style.wrap_right_border; - - return; } /* diff --git a/src/interfaces/ecpg/compatlib/informix.c b/src/interfaces/ecpg/compatlib/informix.c index d921b974aa..a7bbeb9223 100644 --- a/src/interfaces/ecpg/compatlib/informix.c +++ b/src/interfaces/ecpg/compatlib/informix.c @@ -529,7 +529,6 @@ void rtoday(date * d) { PGTYPESdate_today(d); - return; } int @@ -959,7 +958,6 @@ rupshift(char *str) for (; *str != '\0'; str++) if (islower((unsigned char) *str)) *str = toupper((unsigned char) *str); - return; } int diff --git a/src/interfaces/ecpg/pgtypeslib/datetime.c b/src/interfaces/ecpg/pgtypeslib/datetime.c index 71dc1a5ff8..1b253747fc 100644 --- a/src/interfaces/ecpg/pgtypeslib/datetime.c +++ b/src/interfaces/ecpg/pgtypeslib/datetime.c @@ -152,7 +152,6 @@ PGTYPESdate_today(date * d) GetCurrentDateTime(&ts); if (errno == 0) *d = date2j(ts.tm_year, ts.tm_mon, ts.tm_mday) - date2j(2000, 1, 1); - return; } #define PGTYPES_DATE_NUM_MAX_DIGITS 20 /* should suffice for most diff --git a/src/interfaces/ecpg/pgtypeslib/dt_common.c b/src/interfaces/ecpg/pgtypeslib/dt_common.c index c22f657674..c1a3a3e2cb 100644 --- a/src/interfaces/ecpg/pgtypeslib/dt_common.c +++ b/src/interfaces/ecpg/pgtypeslib/dt_common.c @@ -624,8 +624,6 @@ j2date(int jd, int *year, int *month, int *day) quad = julian * 2141 / 65536; *day = julian - 7834 * quad / 256; *month = (quad + 10) % 12 + 1; - - return; } /* j2date() */ /* DecodeSpecial() diff --git a/src/interfaces/ecpg/pgtypeslib/timestamp.c b/src/interfaces/ecpg/pgtypeslib/timestamp.c index 7816e6fdc0..810dd06ee6 100644 --- a/src/interfaces/ecpg/pgtypeslib/timestamp.c +++ b/src/interfaces/ecpg/pgtypeslib/timestamp.c @@ -297,7 +297,6 @@ PGTYPEStimestamp_current(timestamp * ts) GetCurrentDateTime(&tm); if (errno == 0) tm2timestamp(&tm, 0, NULL, ts); - return; } static int diff --git a/src/interfaces/libpq/fe-auth-scram.c b/src/interfaces/libpq/fe-auth-scram.c index 741f566a72..3bfcafa1e0 100644 --- a/src/interfaces/libpq/fe-auth-scram.c +++ b/src/interfaces/libpq/fe-auth-scram.c @@ -279,7 +279,6 @@ pg_fe_scram_exchange(void *opaq, char *input, int inputlen, error: *done = true; *success = false; - return; } /* diff --git a/src/pl/plperl/plperl.c b/src/pl/plperl/plperl.c index 0b224b933c..c78891868a 100644 --- a/src/pl/plperl/plperl.c +++ b/src/pl/plperl/plperl.c @@ -2147,8 +2147,6 @@ plperl_create_sub(plperl_proc_desc *prodesc, const char *s, Oid fn_oid) prodesc->proname))); prodesc->reference = subref; - - return; } @@ -2388,8 +2386,6 @@ plperl_call_perl_event_trigger_func(plperl_proc_desc *desc, PUTBACK; FREETMPS; LEAVE; - - return; } static Datum diff --git a/src/pl/plpgsql/src/pl_exec.c b/src/pl/plpgsql/src/pl_exec.c index 4a9ed83030..4f0de7a811 100644 --- a/src/pl/plpgsql/src/pl_exec.c +++ b/src/pl/plpgsql/src/pl_exec.c @@ -1189,8 +1189,6 @@ plpgsql_exec_event_trigger(PLpgSQL_function *func, EventTriggerData *trigdata) * Pop the error context stack */ error_context_stack = plerrcontext.previous; - - return; } /* diff --git a/src/port/win32error.c b/src/port/win32error.c index f0582c8dad..04a3247cef 100644 --- a/src/port/win32error.c +++ b/src/port/win32error.c @@ -205,5 +205,4 @@ _dosmaperr(unsigned long e) #endif errno = EINVAL; - return; } -- 2.20.1 --d6Gm4EdcadzBjdND-- ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v52 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --gp2pyozrd5pweboh Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v52-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v51 07/10] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 26 ++++++++++++-------------- 1 file changed, 12 insertions(+), 14 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index d6e446d582d..d4c1f0e7652 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -292,6 +292,18 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) MyProc->statusFlags |= PROC_IN_CONCURRENT_REPACK; ProcGlobal->statusFlags[MyProc->pgxactoff] = MyProc->statusFlags; LWLockRelease(ProcArrayLock); + + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose anything. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } /* @@ -523,21 +535,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could wait - * indefinitely for our XID to complete. (The deadlock detector would - * not recognize it because we'd be waiting for ourselves, i.e. no - * real lock conflict.) It would be possible to run in a transaction - * block if we had no XID, but this restriction is simpler for users - * to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --r2slln3zpmilwu22 Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v51-0008-Introduce-an-option-to-make-logical-replication-.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
* [PATCH v53 5/7] Check for transaction block early in ExecRepack @ 2026-04-03 15:23 Srinath Reddy Sadipiralla <[email protected]> 0 siblings, 0 replies; 139+ messages in thread From: Srinath Reddy Sadipiralla @ 2026-04-03 15:23 UTC (permalink / raw) Currently, executing REPACK (CONCURRENTLY) without a table name inside a transaction block throws the error "REPACK CONCURRENTLY requires explicit table name" instead of the expected transaction block error. This occurs because ExecRepack() validates the parsed options and missing relation before verifying the transaction state. This behavior is inconsistent with other utility commands like VACUUM ,REINDEX, etc; which invoke PreventInTransactionBlock() at the very start of their execution to properly reject execution inside user transactions before validating targets. Add PreventInTransactionBlock to the top of ExecRepack() to enforce the transaction block restriction early. This prevents the user from fixing a missing table error only to immediately hit a transaction block error, and also ensures consistency with rest of the commands. Author: Srinath Reddy Sadipiralla <[email protected]> --- src/backend/commands/repack.c | 27 +++++++++++++++------------ 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index f2759cdbef1..8d9b2b2e370 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -279,6 +279,21 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) /* Determine the lock mode to use. */ lockmode = RepackLockLevel((params.options & CLUOPT_CONCURRENT) != 0); + if ((params.options & CLUOPT_CONCURRENT) != 0) + { + /* + * Make sure we're not in a transaction block. + * + * The reason is that repack_setup_logical_decoding() could wait + * indefinitely for our XID to complete. (The deadlock detector would + * not recognize it because we'd be waiting for ourselves, i.e. no + * real lock conflict.) It would be possible to run in a transaction + * block if we had no XID, but this restriction is simpler for users + * to understand and we don't lose any functionality. + */ + PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); + } + /* * If a single relation is specified, process it and we're done ... unless * the relation is a partitioned table, in which case we fall through. @@ -511,19 +526,7 @@ cluster_rel(RepackCommand cmd, Relation OldHeap, Oid indexOid, * replica index OID. */ if (concurrent) - { - /* - * Make sure we're not in a transaction block. - * - * The reason is that repack_setup_logical_decoding() could deadlock - * if there's an XID already assigned. It would be possible to run in - * a transaction block if we had no XID, but this restriction is - * simpler for users to understand and we don't lose anything. - */ - PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); - check_repack_concurrently_requirements(OldHeap, &ident_idx); - } /* Check for user-requested abort. */ CHECK_FOR_INTERRUPTS(); -- 2.47.3 --qr3jlalmmcpkiodg Content-Type: text/x-diff; charset=utf-8 Content-Disposition: attachment; filename="v53-0006-Error-out-any-process-that-would-block-at-REPACK.patch" ^ permalink raw reply [nested|flat] 139+ messages in thread
end of thread, other threads:[~2026-04-03 15:23 UTC | newest] Thread overview: 139+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2019-11-27 13:28 [PATCH] Remove useless "return;" lines Alvaro Herrera <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v52 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v51 07/10] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]> 2026-04-03 15:23 [PATCH v53 5/7] Check for transaction block early in ExecRepack Srinath Reddy Sadipiralla <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox