Re: [bug] Table not have typarray when created by single user mode

Wenjing Zeng <wjzeng2012@gmail.com>

From: wenjing zeng <wjzeng2012@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, shawn wang <shawn.wang.pg@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org, tushar <tushar.ahuja@enterprisedb.com>
Date: 2020-05-21T07:28:28Z
Lists: pgsql-bugs, pgsql-hackers

Attachments


> 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



Commits

  1. Don't create pg_type entries for sequences or toast tables.

  2. Create composite array types for initdb-created relations.