From: Antonin Houska <ah@cybertec.at>
To: shihao zhong <zhong950419@gmail.com>
cc: Alvaro Herrera <alvherre@kurilemu.de>,
    Fujii Masao <masao.fujii@gmail.com>,
    Radim Marek <radim@boringsql.com>,
    PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: REPACK (CONCURRENTLY) might keep dropped-column data
In-reply-to: 
 <CAGRkXqTxse0sTb43z3kFAHDrffjkamHkFGfoLEtwRkr_QfDGGg@mail.gmail.com>
References: 
 <CAHGQGwG9bHxhs4Nj+9avSjSGh0vdYNQgEuz+pmJ-H5be6tEBTw@mail.gmail.com>
 <asOEsmPw75ifqMua@alvherre.pgsql>
 <CAGRkXqTxse0sTb43z3kFAHDrffjkamHkFGfoLEtwRkr_QfDGGg@mail.gmail.com>
Comments: In-reply-to shihao zhong <zhong950419@gmail.com>
   message dated "Mon, 05 Oct 2026 11:46:54 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <12437.1791272113.1@localhost>
Date: Tue, 06 Oct 2026 09:35:13 +0200
Message-ID: <12438.1791272113@localhost>
Archived-At: 
 <https://www.postgresql.org/message-id/12438.1791272113%40localhost>
Precedence: bulk

shihao zhong <zhong950419@gmail.com> wrote:

> A replayed INSERT can carry a dropped column's value too, and that
> path still stores it.
> 
> A BEFORE INSERT trigger that returns a copy of
> an existing row does it:
> 
> r := (SELECT t FROM demo t WHERE id = 1);
> r.id := NEW.id;
> RETURN r;
> 
> So does an UPDATE that moves the row to another partition while the
> trigger returns OLD. COPY, MERGE and INSERT ON CONFLICT go the same
> way.


> 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? */


> 0001 clears dropped columns in restore_tuple(), so every kind of
> change is covered, and the block added to prepare_concurrent_update()
> is no longer needed.

Is this needed even for DELETE?

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