> 2020年5月20日 上午12:09，Tom Lane <tgl@sss.pgh.pa.us> 写道：
>
> 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.)
Thanks for your help, This method passed all regression tests and pg_upgrade checks.
It looks perfect.
Wenjing
>
> 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
