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 17717.1570991208@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  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-bugs
Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> 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.

Might be a good idea to exclude attisdropped columns in the part of the
recursive query that's looking for sql_identifier columns of composite
types.  I'm not sure if composites can have dropped columns today,
but even if they can't it seems like a wise bit of future-proofing.
(We'll no doubt have occasion to use this logic again...)

Looks good other than that nit.

> 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.

Yeah, we should back-port this logic into that check too, IMO.

            regards, tom lane



В списке pgsql-bugs по дате отправления:

Предыдущее
От: "McLaughlin, Michael"
Дата:
Сообщение: ERROR: invalid input syntax for integer: "0A000"
Следующее
От: Tom Lane
Дата:
Сообщение: Re: ERROR: invalid input syntax for integer: "0A000"