| From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org, alvherre(at)kurilemu(dot)de |
| Subject: | Re: REPACK (CONCURRENTLY) doesn't check the table AM |
| Date: | 2026-08-27 18:59:10 |
| Message-ID: | CALj2ACUGsWsWB-OvKxxWneRZLB4fVuQ9C2OEvzA-0hPe8VJXsg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On Thu, Aug 27, 2026 at 9:23 AM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> REPACK (CONCURRENTLY) replays changes by decoding them from WAL, so it
> needs the table AM to be logically decodable, but
> check_concurrent_repack_requirements() doesn't check that. Should it be
> restricted to heap for v19?
Logical decoding doesn't check the table AM type, but goes ahead and
decodes the WAL records (for that matter, none of CLUSTER, VACUUM
FULL, and REPACK have checks on table AM. They hand off at some point
to the table AM layer). I'm not sure if gating it just for concurrent
repack is the right choice. Is it that we want to have it just for
concurrent repack since it's new code with a new logical decoding
plugin and we want some field reports of needing it for other table
AMs?
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-08-27 19:16:19 | Re: REPACK (CONCURRENTLY) doesn't check the table AM |
| Previous Message | Matheus Alcantara | 2026-08-27 18:55:11 | Re: REPACK (CONCURRENTLY) fails when table owner lacks CONNECT |