Re: bug, ALTER TABLE call ATPostAlterTypeCleanup twice for the same relation

On Wed, Oct 1, 2025 at 11:04 AM jian he <jian.universality@gmail.com> wrote:
>
> we can simply change from
>
>             if (pass == AT_PASS_ALTER_TYPE || pass == AT_PASS_SET_EXPRESSION)
>                 ATPostAlterTypeCleanup(wqueue, tab, lockmode);
>
> to
>             if (pass == AT_PASS_SET_EXPRESSION)
>                 ATPostAlterTypeCleanup(wqueue, tab, lockmode);
>             else if (pass == AT_PASS_ALTER_TYPE &&
>                      tab->subcmds[AT_PASS_SET_EXPRESSION] == NIL)
>                 ATPostAlterTypeCleanup(wqueue, tab, lockmode);

That will not work if AT_PASS_ALTER_TYPE triggers the creation of a new
AT_PASS_SET_EXPRESSION entry.
For example, consider:
CREATE TABLE gtest25 (a int, b int GENERATED ALWAYS AS (a * 2) STORED);

If we alter the type of column "a", the column b’s generation
expression would need
to be rebuilt (which is currently not supported).  In that case, the current
logic would not be able to handle it.

I think the correct fix is within ATPostAlterTypeCleanup.
at the end of ATPostAlterTypeCleanup, we already delete these changed
objects via
``performMultipleDeletions(objects, DROP_RESTRICT, PERFORM_DELETION_INTERNAL);``

we can just list_free these (the below) objects too:
    tab->changedConstraintOids
    tab->changedConstraintDefs
    tab->changedIndexOids
    tab->changedIndexDefs
    tab->changedStatisticsOids
    tab->changedStatisticsDefs

since this information would become stale if those objects have
already been dropped.