Re: pg_upgrade and materialized views

Andres Freund <andres(at)anarazel(dot)de> writes:
> On February 20, 2018 3:44:47 PM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Anyway, I'm thinking the core of the problem here is that we've got
>> multiple places that know which relkinds are physically transferred
>> during a pg_upgrade, and they don't all know the same thing. We
>> need to centralize that knowledge somehow, or we're going to be
>> singing this same tune again in the future. Not quite sure where
>> to put it though. pg_dump and pg_upgrade both need to know that,
>> but the backend doesn't, so I don't quite want to add it in
>> pg_class.h where the core list of relkinds is.

> Why do we need any relkind checks here at all? Shouldn't we just transport all xid horizons that are set before into the new cluster without filtering?

The ones on relations without storage are meaningless, and I'm not
sure it's a good idea to set them nonzero if they're zero initially.
In any case, pg_upgrade *has to* be selective about which files it
tries to physically transfer --- even skipping nonexistent files
wouldn't be good enough, since it should not transfer sequence files.

Also, you were right to complain before that some of the issue here
is considering "must hack dropped columns" to be identical to
"must hack relfrozenxid". It's not clear that that's true, eg
I think the answer is different for RELKIND_PARTITIONED_TABLE.

regards, tom lane