Re: pg_upgrade and materialized views

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?

And update all preexisting objects that have an xid set to the new the old cluster's nextxid?

Andres

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.