Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12
От | Tom Lane |
---|---|
Тема | Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12 |
Дата | |
Msg-id | 20265.1570664514@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16045: vacuum_db crash and illegal memory alloc afterpg_upgrade from PG11 to PG12 (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: BUG #16045: vacuum_db crash and illegal memory alloc afterpg_upgrade from PG11 to PG12
|
Список | pgsql-bugs |
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes: > On Wed, Oct 09, 2019 at 07:18:45PM -0400, Tom Lane wrote: >> Fortunately, there should be close to zero people with user tables >> depending on sql_identifier. I think we should just add a test in >> pg_upgrade that refuses to upgrade if there are any such columns. >> It won't be the first such restriction. > Hmmm, yeah. I agree the number of people using sql_identifier in user > tables is low, but OTOH we got this report within a week after release, > so maybe it's higher than we think. True. > Another option would be to teach pg_upgrade to switch the columns to > 'text' or 'varchar', not sure if that's possible or how much work would > that be. I think it'd be a mess --- the actual hacking would have to happen in pg_dump, I think, and it'd be a kluge because pg_dump doesn't normally understand what server version its output is going to. So we'd more or less have to control it through a new pg_dump switch that pg_upgrade would use. Ick. Also, even if we did try to silently convert such columns that way, I bet we'd get other bug reports about "why'd my columns suddenly change type?". So I'd rather force the user to be involved. regards, tom lane
В списке pgsql-bugs по дате отправления: