Re: pg_upgrade in 9.5 broken for adminpack
| От | Jeff Janes |
|---|---|
| Тема | Re: pg_upgrade in 9.5 broken for adminpack |
| Дата | |
| Msg-id | CAMkU=1xA9m0KG1JXi08M53hn18bTm4ew2Pq6n5WsKdC+-K4wAw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_upgrade in 9.5 broken for adminpack (Jeff Janes <jeff.janes@gmail.com>) |
| Ответы |
Re: pg_upgrade in 9.5 broken for adminpack
Re: pg_upgrade in 9.5 broken for adminpack |
| Список | pgsql-hackers |
On Thu, Apr 16, 2015 at 11:04 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
On Thu, Apr 16, 2015 at 7:37 PM, Bruce Momjian <bruce@momjian.us> wrote:On Thu, Apr 16, 2015 at 07:33:50PM -0700, Jeff Janes wrote:
> pg_upgrade was recently broken for use upgrading from a system with adminpack
> installed.
>
...
The query:SELECT pg_catalog.binary_upgrade_create_empty_extension('adminpack', 'pg_catalog', false, '1.0', NULL, NULL, ARRAY[]::pg_catalog.text[]);doesnt' seem to do anything. It returns NULL, but doesn't create an extension. I set a gdb breakpoint on binary_upgrade_create_empty_extension and it never trips when manually running the above query.If the SQL function never calls the C function, what is it doing?
Of course after sending that it became obvious. The C function is not getting called because the SQL function is marked as being strict, yet is called with NULL arguments.
Trivial patch attached to unset strict flag in pg_proc.h.
But CATALOG_VERSION_NO probably needs another bump as well.
Cheers,
Jeff
Вложения
В списке pgsql-hackers по дате отправления: