Re: REPACK (CONCURRENTLY) might keep dropped-column data

From: Antonin Houska <ah(at)cybertec(dot)at>
To:
Cc: shihao zhong <zhong950419(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)kurilemu(dot)de>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Radim Marek <radim(at)boringsql(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
Date: 2026-10-06 10:44:12
Message-ID: 31417.1791283452@localhost
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Antonin Houska <ah(at)cybertec(dot)at> wrote:

> shihao zhong <zhong950419(at)gmail(dot)com> wrote:
>
> > It can also make REPACK fail. If the columns that are left need no
> > TOAST table, the new heap has none, and on master I get:
> >
> > ERROR: row is too big: size 16424, maximum size 8160
>
> Can you please be more specific about this? I don't understand why the new
> heap has no TOAST relation in such a case. Perhaps a bug in see
> heapam_relation_needs_toast_table()? I'm not sure it should return here,
> regardless the tuple size.
>
> if (!has_toastable_attrs)
> return false; /* nothing to toast? */

I could reproduce error like this independently from REPACK - see the scripts
attached. However, I realize that it does not help to remove this part from
heapam_relation_needs_toast_table(): it would only enforce creation of the
TOAST table if all the attributes had storage TYPSTORAGE_PLAIN, but such
attributes cannot be TOASTed anyway.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com

Attachment Content-Type Size
create.sql.gz application/gzip 3.7 KB
insert.sql.gz application/gzip 83 bytes

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message vignesh C 2026-10-06 10:57:47 Re: Parallel Apply
Previous Message Alena Rybakina 2026-10-06 10:37:57 Re: Vacuum statistics