From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | Bruce Momjian <bruce(at)momjian(dot)us> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_upgrade in 9.5 broken for adminpack |
Date: | 2015-04-17 06:29:07 |
Message-ID: | CAMkU=1xA9m0KG1JXi08M53hn18bTm4ew2Pq6n5WsKdC+-K4wAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 16, 2015 at 11:04 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
>
> On Thu, Apr 16, 2015 at 7:37 PM, Bruce Momjian <bruce(at)momjian(dot)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
Attachment | Content-Type | Size |
---|---|---|
pg_upgrade_support_strict.patch | application/octet-stream | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2015-04-17 07:11:44 | Re: pg_upgrade in 9.5 broken for adminpack |
Previous Message | Jeff Janes | 2015-04-17 06:04:07 | Re: pg_upgrade in 9.5 broken for adminpack |