Re: [bug] Table not have typarray when created by single user mode
От | wenjing zeng |
---|---|
Тема | Re: [bug] Table not have typarray when created by single user mode |
Дата | |
Msg-id | ABF24C4F-5F44-423A-9EFC-1029CFCA16EC@gmail.com обсуждение исходный текст |
Ответ на | Re: [bug] Table not have typarray when created by single user mode (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-bugs |
> 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
Вложения
В списке pgsql-bugs по дате отправления: