Claudio Freire <klaussfreire@gmail.com> writes:
>> Well, the attached script reproduces the issue.
One thing this doesn't prove by itself is whether the use of
REFRESH MATERIALIZED VIEW CONCURRENTLY has any effect on the
situation.
I poked at that a bit and noted that REFRESH MATERIALIZED VIEW
CONCURRENTLY doesn't seem to change the matview's relfrozenxid
at all, while a plain REFRESH advances the matview's relfrozenxid
to (more or less) the current xid counter. That probably isn't
a bug, but maybe there's a missed optimization opportunity there.
At any rate, the matview's relfrozenxid isn't going backwards,
so my original fear seems unfounded.
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.
regards, tom lane