Re: [PATCH] Improve REPACK (CONCURRENTLY) error messages for unsupported configurations

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Baji Shaik <baji(dot)pgdev(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: [PATCH] Improve REPACK (CONCURRENTLY) error messages for unsupported configurations
Date: 2026-05-27 06:50:01
Message-ID: 172EB2C2-DE11-4E5B-B115-38A7AD3B6A3D@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On May 27, 2026, at 11:06, Baji Shaik <baji(dot)pgdev(at)gmail(dot)com> wrote:
>
> Hi,
>
> While exploring the new REPACK (CONCURRENTLY) feature, I noticed
> a few user-facing error paths that could be made more accurate.
> Patch series of three:
>
> 0001 -- When wal_level < replica, REPACK (CONCURRENTLY) currently
> surfaces generic "replication slots ... wal_level" error
> from CheckSlotRequirements(), with a CONTEXT line referring
> to an internal worker. Add an upfront check that reports a
> REPACK-specific error.
>

LGTM

> 0002 -- check_concurrent_repack_requirements() reports the same
> generic "no identity index" error for several distinct
> cases, two of which are misleading: REPLICA IDENTITY FULL
> (which is set, but the hint says there is no identity), and
> a deferrable PK as the only identity (skipped per commit
> 832e220d99a, but the hint suggests adding an index that
> already exists). Distinguish these cases.
>

When I was working on 832e220d99a, I actually considered for more detailed error messages, but I ended up giving up. I think we should be careful about adding more branches here unless the existing message is causing significant confusion in practice.

So, I personally don’t like 0002.

> 0003 -- Four ereport(ERROR) calls in the REPACK CONCURRENTLY code
> path lack errcode() and default to ERRCODE_INTERNAL_ERROR.
> Add appropriate errcodes; in particular, the
> apply_concurrent_update/delete failures map cleanly to
> ERRCODE_T_R_SERIALIZATION_FAILURE.
>

LGTM

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Corey Huinker 2026-05-27 06:37:56 Re: remove pg_spin_delay() from atomics code