Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
От | Bruce Momjian |
---|---|
Тема | Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2 |
Дата | |
Msg-id | 20120601154859.GA26503@momjian.us обсуждение исходный текст |
Ответ на | Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2 (Bruce Momjian <bruce@momjian.us>) |
Ответы |
Re: BUG #6666: pg_upgrade 9.2beta1 plpython/plpython2
|
Список | pgsql-bugs |
On Thu, May 31, 2012 at 09:37:06PM -0400, Bruce Momjian wrote: > > I share Tom's caution on this, but I think we need to make sure we are > > addressing any possible risk of an isolated pg_upgrade fix, now that we > > understand the cause. > > FYI, this query will show any functions defined in the public schema > who's names match pg_pltemplate helper functions: > > SELECT proname > FROM pg_proc JOIN pg_namespace ON (pronamespace = pg_namespace.oid) > WHERE proname IN > ( > SELECT tmplhandler FROM pg_pltemplate > UNION > SELECT tmplinline FROM pg_pltemplate > UNION > SELECT tmplvalidator FROM pg_pltemplate > ) AND > nspname = 'public'; > > This is normal in pre-8.1 but might indicate orphaned functions in PG > 8.1+. OK, based on the lack of excitement in doing anything more invasive, I have applied the pg_upgrade fix to PG 9.2 for the plpython helper function appearing in the public schema and referencing an old shared library. Should this be back-patched? (Problem first reported in PG 9.1 due to the removal of a backward-compatibility symlink.) I am not sure we have had enough problem reports to warrant it (3 reports). (Should bug discussions stay on the bugs list? I did for this bug.) -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-bugs по дате отправления: