agora inbox for pgsql-hackers@postgresql.orghelp / color / mirror / Atom feed
[PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. 109+ messages / 1 participants [nested] [flat]
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
* [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. @ 2026-08-28 17:53 Antonin Houska <ah@cybertec.at> 0 siblings, 0 replies; 109+ messages in thread From: Antonin Houska @ 2026-08-28 17:53 UTC (permalink / raw) If REPACK (ANALYZE) is called from a pl/pgsql function, cluster_rel() might start a new transaction while SPI session is in progress. Use PreventInTransactionBlock() to avoid that. That function also raises error if REPACK (ANALYZE) is called in a transaction block, but that's fine: VACUUM (FULL, ANALYZE) - a synonym of REPACK (ANALYZE) - also raises ERROR in that case. --- src/backend/commands/repack.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) diff --git a/src/backend/commands/repack.c b/src/backend/commands/repack.c index 477c86b2ba6..81877029199 100644 --- a/src/backend/commands/repack.c +++ b/src/backend/commands/repack.c @@ -314,6 +314,20 @@ ExecRepack(ParseState *pstate, RepackStmt *stmt, bool isTopLevel) */ PreventInTransactionBlock(isTopLevel, "REPACK (CONCURRENTLY)"); } + else if ((params.options & CLUOPT_ANALYZE) != 0) + { + /* + * Technically, transaction block is not a problem for REPACK + * (ANALYZE), but if it's called from a pl/pgsql function, + * cluster_rel() might start a new transaction while SPI session is in + * progress. Make sure ERROR is raised instead. + * + * This way we also prohibit execution in a transaction block, but + * that's just consistent with VACUUM (FULL, ANALYZE), which is a + * synonym for REPACK (ANALYZE). + */ + PreventInTransactionBlock(isTopLevel, "REPACK (ANALYZE)"); + } /* * If a single relation is specified, process it and we're done ... unless -- 2.52.0 --=-=-=-- ^ permalink raw reply [nested|flat] 109+ messages in thread
end of thread, other threads:[~2026-08-28 17:53 UTC | newest] Thread overview: 109+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at> 2026-08-28 17:53 [PATCH] Do not allow REPACK (ANALYZE) in function and in transaction block. Antonin Houska <ah@cybertec.at>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox