agora inbox for [email protected]help / color / mirror / Atom feed
Re: Tying an object's ownership to datdba 2890+ messages / 3 participants [nested] [flat]
* Re: Tying an object's ownership to datdba @ 2021-03-24 15:57 John Naylor <[email protected]> 2021-03-25 04:07 ` Re: Tying an object's ownership to datdba Noah Misch <[email protected]> 0 siblings, 1 reply; 2890+ messages in thread From: John Naylor @ 2021-03-24 15:57 UTC (permalink / raw) To: Noah Misch <[email protected]>; +Cc: pgsql-hackers On Mon, Dec 28, 2020 at 12:32 AM Noah Misch <[email protected]> wrote: > [v2] Hi Noah, In the refactoring patch, there is a lingering comment reference to roles_has_privs_of(). Aside from that, it looks good to me. A possible thing to consider is an assert that is_admin is not null where we expect that. The database owner role patch looks good as well. > I ended up blocking DDL that creates role memberships involving the new role; > see reasons in user.c comments. Lifting those restrictions looked feasible, > but it was inessential to the mission, and avoiding unintended consequences > would have been tricky. Views "information_schema.enabled_roles" and > "information_schema.applicable_roles" list any implicit membership in > pg_database_owner, but pg_catalog.pg_group and psql \dgS do not. If this > leads any reviewer to look closely at applicable_roles, note that its behavior > doesn't match its documentation > (https://postgr.es/m/flat/[email protected]). Is this something that needs fixing separately? -- John Naylor EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 2890+ messages in thread
* Re: Tying an object's ownership to datdba 2021-03-24 15:57 Re: Tying an object's ownership to datdba John Naylor <[email protected]> @ 2021-03-25 04:07 ` Noah Misch <[email protected]> 2021-03-25 13:55 ` Re: Tying an object's ownership to datdba John Naylor <[email protected]> 0 siblings, 1 reply; 2890+ messages in thread From: Noah Misch @ 2021-03-25 04:07 UTC (permalink / raw) To: John Naylor <[email protected]>; +Cc: pgsql-hackers On Wed, Mar 24, 2021 at 11:57:37AM -0400, John Naylor wrote: > On Mon, Dec 28, 2020 at 12:32 AM Noah Misch <[email protected]> wrote: > > [v2] > > Hi Noah, > > In the refactoring patch, there is a lingering comment reference to roles_has_privs_of(). Aside from that, it looks good to me. A possible thing to consider is an assert that is_admin is not null where we expect that. Thanks. The next version will contain the comment fix and "Assert(OidIsValid(admin_of) == PointerIsValid(is_admin));". > The database owner role patch looks good as well. Do you plan to put the CF entry into Ready for Committer, or should the patches wait for another review? > > I ended up blocking DDL that creates role memberships involving the new role; > > see reasons in user.c comments. Lifting those restrictions looked feasible, > > but it was inessential to the mission, and avoiding unintended consequences > > would have been tricky. Views "information_schema.enabled_roles" and > > "information_schema.applicable_roles" list any implicit membership in > > pg_database_owner, but pg_catalog.pg_group and psql \dgS do not. If this > > leads any reviewer to look closely at applicable_roles, note that its behavior > > doesn't match its documentation > > (https://postgr.es/m/flat/[email protected]). > > Is this something that needs fixing separately? It is bug, but I think fixing it is not very urgent and should happen separately, if at all. ^ permalink raw reply [nested|flat] 2890+ messages in thread
* Re: Tying an object's ownership to datdba 2021-03-24 15:57 Re: Tying an object's ownership to datdba John Naylor <[email protected]> 2021-03-25 04:07 ` Re: Tying an object's ownership to datdba Noah Misch <[email protected]> @ 2021-03-25 13:55 ` John Naylor <[email protected]> 0 siblings, 0 replies; 2890+ messages in thread From: John Naylor @ 2021-03-25 13:55 UTC (permalink / raw) To: Noah Misch <[email protected]>; +Cc: pgsql-hackers On Thu, Mar 25, 2021 at 12:07 AM Noah Misch <[email protected]> wrote: > > > In the refactoring patch, there is a lingering comment reference to roles_has_privs_of(). Aside from that, it looks good to me. A possible thing to consider is an assert that is_admin is not null where we expect that. > > Thanks. The next version will contain the comment fix and > "Assert(OidIsValid(admin_of) == PointerIsValid(is_admin));". > > > The database owner role patch looks good as well. > > Do you plan to put the CF entry into Ready for Committer, or should the > patches wait for another review? I've marked it Ready for Committer. -- John Naylor EDB: http://www.enterprisedb.com ^ permalink raw reply [nested|flat] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ 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; 2890+ 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] 2890+ messages in thread
end of thread, other threads:[~2026-04-03 15:23 UTC | newest] Thread overview: 2890+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2021-03-24 15:57 Re: Tying an object's ownership to datdba John Naylor <[email protected]> 2021-03-25 04:07 ` Noah Misch <[email protected]> 2021-03-25 13:55 ` John Naylor <[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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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]> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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]> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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]> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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]> 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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 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]> 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 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 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 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 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]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox