Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> I think the argument to have that error check there, is that it's a
> cross-check to avoid pg_upgrade bugs for cases where
> binary_upgrade_next_array_type_oid is not set when it should have been
> set. But I think we've hammered the pg_upgrade code sufficiently now,
> that we don't need that check anymore. Any bugs that result in that
> behavior will be very evident by lack of consistency on some upgrade
> anyway.
I don't buy that argument at all; that's a pretty critical cross-check
IMO, because it's quite important that pg_upgrade control all type OIDs
assigned in the new cluster. And I think it's probably easier to
break than you're hoping :-(
I think a safer fix is to replace the IsUnderPostmaster check in
heap_create_with_catalog with !IsBootstrapProcessingMode() or the
like. That would have the result that we'd create array types for
the information_schema views, as well as the system views made in
system_views.sql, which is slightly annoying but probably no real
harm in the big scheme of things. (I wonder if we ought to reverse
the sense of the adjacent relkind check, turning it into a blacklist,
while at it.)
I remain however of the opinion that doing this sort of thing in
single-user mode, or really much of anything beyond emergency
vacuuming, is unwise.
regards, tom lane
