shihao zhong <[email protected]> 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
