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

shihao zhong <zhong950419(at)gmail(dot)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