Re: [HACKERS] pg_upgrade and missing loadable libraries
| От | Bruce Momjian |
|---|---|
| Тема | Re: [HACKERS] pg_upgrade and missing loadable libraries |
| Дата | |
| Msg-id | 20170604181632.GE2672@momjian.us обсуждение исходный текст |
| Ответ на | Re: [HACKERS] pg_upgrade and missing loadable libraries (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [HACKERS] pg_upgrade and missing loadable libraries
|
| Список | pgsql-hackers |
On Sun, Jun 4, 2017 at 02:04:37PM -0400, Tom Lane wrote: > Bruce Momjian <bruce@momjian.us> writes: > > The problem is that in some cases extensions are improperly removed or > > the extension has bugs that leaves pg_proc entries around that aren't > > dumped, but are seen by pg_upgrade and generate an error. In these > > cases, and I have seen a few recently, we don't give the user any way to > > find the cause except ask for assistance, i.e. we don't show them the > > query we used to find the problem libraries. > > Meh. I think that sort of situation is one in which non-experts are > going to need help in any case. It's unlikely that pg_upgrade can, > or should try to, offer them advice sufficient to fix the problem. > > Also, I completely reject the idea that pg_upgrade's output should > be optimized for that situation rather than the typical "you forgot > to install these extensions in the new installation" case. I didn't want to optimize for it --- I wanted a way to detect when DROP EXTENSION has no hope of working, and give more details. I assume the problem with that is the the object names are inside SQL scripts that cannot be easily interrogated. Are the pg_proc entries tied to the extension in some verifiable way that we could identify orphaned pg_proc lines? -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + As you are, so once was I. As I am, so you will be. + + Ancient Roman grave inscription +
В списке pgsql-hackers по дате отправления: