Re: pg_upgrade in 9.5 broken for adminpack - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: pg_upgrade in 9.5 broken for adminpack
Date
Msg-id CAMkU=1xA9m0KG1JXi08M53hn18bTm4ew2Pq6n5WsKdC+-K4wAw@mail.gmail.com
Whole thread Raw
In response to Re: pg_upgrade in 9.5 broken for adminpack  (Jeff Janes <jeff.janes@gmail.com>)
Responses Re: pg_upgrade in 9.5 broken for adminpack
Re: pg_upgrade in 9.5 broken for adminpack
List 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

Attachment

pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: pg_upgrade in 9.5 broken for adminpack
Next
From: Michael Paquier
Date:
Subject: Re: pg_upgrade in 9.5 broken for adminpack