Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
От | Tom Lane |
---|---|
Тема | Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed |
Дата | |
Msg-id | 2816651.1611942942@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed (GMX LINREG <linreg@gmx.net>) |
Ответы |
Re: BUG #16843: pg_upgrade from 12.5 to 13.1 with extension plperlu failed
|
Список | pgsql-bugs |
GMX LINREG <linreg@gmx.net> writes: > output from source database: > botdb=# \dx+ plperlu > Objekte in Erweiterung »plperlu« > Objektbeschreibung > -------------------- > language plperlu Yeah, that's definitely broken: it should look like \dx+ plperlu Objects in extension "plperlu" Object description ------------------------------------------- function plperlu_call_handler() function plperlu_inline_handler(internal) function plperlu_validator(oid) language plperlu (4 rows) Offhand I think that completely explains pg_dump's failure: it relies on the dependency-membership entries to decide that it ought to dump the language support functions, so if they're not there, this is what you get. It's possible that the entries *are* there but they're not being found due to index corruption. You could try "REINDEX TABLE pg_depend" and see if the \dx+ output changes. I don't have a lot of hope for that though. The next easiest fix would be to see if you have any plperlu functions to worry about, and if not, just drop the busted extension. If you do have some such functions, the best bet might be to dump them separately, go ahead and DROP CASCADE the busted extension, then upgrade; and restore the plperlu functions separately afterwards. It'd be kind of interesting to figure out why those pg_depend entries are missing, but I suppose the evidence is long gone :-( regards, tom lane
В списке pgsql-bugs по дате отправления: