Re: [HACKERS] pg_upgrade and missing loadable libraries
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] pg_upgrade and missing loadable libraries |
Дата | |
Msg-id | 11687.1496598901@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] pg_upgrade and missing loadable libraries (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: [HACKERS] pg_upgrade and missing loadable libraries
|
Список | pgsql-hackers |
Bruce Momjian <bruce@momjian.us> writes: > On Sun, Jun 4, 2017 at 01:20:12PM -0400, Alvaro Herrera wrote: >> I think it'd be better to be exhaustive about the report, i.e. report >> all problems in all databases, if possible. Doing repeated pg_upgrade >> attempts until you've nailed all the problems is boring ... > Well, I think there are three open items: > * should we print all the database names involved Yes. > * should we print all the pg_proc.pronames that are involved, not just > the unique library names > * should we output a query helping people find the pg_proc entries > I think there are many cases where DROP EXTENSION XXX fixes the problem, Yes. I think in most cases nowadays there's a one-for-one correlation between extensions and libraries; drilling down to the level of individual functions would just be confusing clutter. I think if you just print a report saying "these libraries are referenced in these databases", that would be sufficiently usable in most cases. You could think about printing a script full of DROP EXTENSION commands, but aside from the sheer difficulty of doing that, it doesn't seem all that helpful. Simply dropping every extension is usually *not* the right answer, and it could easily lead to data loss if done blindly. Usually people are going to need to stop and think anyway. regards, tom lane
В списке pgsql-hackers по дате отправления: