On Thu, Apr 16, 2015 at 7:37 PM, Bruce Momjian <br...@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.
> >
> > Breaking commit is:
> >
> > commit 30982be4e5019684e1772dd9170aaa53f5a8e894
> > Author: Peter Eisentraut <pete...@gmx.net>
> >
> > Integrate pg_upgrade_support module into backend
> >
> >
> > from pg_upgrade_dump_12870.log
> >
> > pg_restore: creating EXTENSION "adminpack"
> > pg_restore: creating COMMENT "EXTENSION "adminpack""
> > pg_restore: [archiver (db)] Error while PROCESSING TOC:
> > pg_restore: [archiver (db)] Error from TOC entry 2806; 0 0 COMMENT
> EXTENSION
> > "adminpack"
> > pg_restore: [archiver (db)] could not execute query: ERROR: extension
> > "adminpack" does not exist
> > Command was: COMMENT ON EXTENSION "adminpack" IS 'administrative
> functions
> > for PostgreSQL';
> >
> >
> > I get the same error whether the source database is 9.2.10 or 9.5.HEAD.
>
> Uh, I am confused how moving pg_upgrade or pg_upgrade_support would
> break the loading of the "adminpack" extension.
>
Yeah, I'm confused to. But I see it isn't just adminpack, it is all
extensions.
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?
Cheers,
Jeff
