|From:||Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Andres Freund <andres(at)anarazel(dot)de>, buschmann(at)nidsa(dot)net, pgsql-bugs(at)lists(dot)postgresql(dot)org|
|Subject:||Re: BUG #16045: vacuum_db crash and illegal memory alloc after pg_upgrade from PG11 to PG12|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
here is an updated patch, with the recursive CTE. I've done a fair
amount of testing on it on older versions (up to 9.4), and it seems to
work just fine.
Another thing that I noticed is that the query does not need to look at
RELKIND_COMPOSITE_TYPE, because we only really care about cases when
sql_identifier is stored on-disk. Composite type alone does not do that,
and the CTE includes OIDs of composite types that we then check against
relations and matviews.
Barring objections, I'll push this early next week.
BTW the query (including the RELKIND_COMPSITE_TYPE) was essentially just
a lightly-massaged copy of old_9_6_check_for_unknown_data_type_usage, so
that seems wrong too. The comment explicitly says:
* Also check composite types, in case they are used for table columns.
but even a simple "create type c as (a unknown, b int)" without any
table using it enough to trigger the failure. But maybe it's
intentional, not sure.
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
|Next Message||McLaughlin, Michael||2019-10-13 17:44:25||ERROR: invalid input syntax for integer: "0A000"|
|Previous Message||Andrew Gierth||2019-10-12 17:17:21||Re: BUG #16053: Query planner performance regression in sql query with multiple CTE in v12|
|Next Message||Thomas Munro||2019-10-13 00:44:59||Re: stress test for parallel workers|
|Previous Message||Tom Lane||2019-10-13 00:09:06||Re: v12.0: ERROR: could not find pathkey item to sort|