| From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
|---|---|
| To: | Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com> |
| Cc: | Antonin Houska <ah(at)cybertec(dot)at>, Mihail Nikalayeu <mihailnikalayeu(at)gmail(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Robert Treat <rob(at)xzilla(dot)net> |
| Subject: | Re: Adding REPACK [concurrently] |
| Date: | 2026-03-26 19:15:14 |
| Message-ID: | 202603261900.qbqphzjnlz7s@alvherre.pgsql |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2026-Mar-25, Srinath Reddy Sadipiralla wrote:
> Hello,
>
> While reviewing/testing V44 patch set , i found that if we run REPACK
> (CONCURRENTLY) without a table name inside a transaction block throws
> the error "REPACK CONCURRENTLY requires explicit table name" instead
> of the expected transaction block error. This occurs because
> ExecRepack() validates the parsed options and missing relation before
> verifying the transaction state.
>
> I attached a patch below to maintain consistency with other commands
> like VACUUM, REINDEX , and more and also not to confuse the user ,
> because if user runs REPACK (CONCURRENTLY) without a table name inside
> a transaction block, if user gets "REPACK CONCURRENTLY requires
> explicit table name" and then to correct the mistake the user gives
> table and again runs the in transaction block , just to find out a new
> error "cannot run inside a transaction block".
I don't disagree with changing this, but AFAICS the patch as presented
provokes multiple test failures.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2026-03-26 19:17:39 | Re: Document How Commit Handles Aborted Transactions |
| Previous Message | Sami Imseih | 2026-03-26 18:34:38 | Rename LWLockNewTrancheId() parameter from "name" to "tranche_name" |