Re: pg_upgrade and materialized views

On 2018-02-20 17:05:29 -0500, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > The important part then happens in pg_dump. Note
>
> > if (dopt->binary_upgrade &&
> > (tbinfo->relkind == RELKIND_RELATION ||
> > tbinfo->relkind == RELKIND_FOREIGN_TABLE ||
> > tbinfo->relkind == RELKIND_PARTITIONED_TABLE))
>
> > note that the above if clause doesn't include materialized tables. Which
> > sems to explain this bug? Could you check that just updating the above
> > if to include matviews fixes the bug for you?
>
> I'm also wondering why it *does* include foreign tables. Surely
> relfrozenxid is meaningless for a FT?

I think it's because that if block originally was concerned about
reconstructing table order, rather than relfrozenxid management. For
that the conditions make sense - matviews can't have columns
added/dropped but foreign tables can. That's why I'm suggesting to move
the relfrozenxid handling out of there, it seems very likely to cause
similar problems down the road.

> > Looking into this I also saw:
> > set_frozenxids(bool minmxid_only)
> > which makes a bit uncomfortable, but I can't quite put my finger on
> > why.
>
> The fact that it's inconsistent with the other list is surely a red flag,
> eg seems like we should include RELKIND_PARTITIONED_TABLE there too.

If I understand correctly the purpose of set_frozenxid() is to update
the horizons of system tables, *before* restoring the schema dump. So I
think excluding RELKIND_PARTITIONED_TABLE is harmless for now (i.e. we
can just change it in master).

I wonder if there's a scenario in which a schema restore uses enough
xids to get close to anti-wraparound territory?

Greetings,

Andres Freund