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. > > Breaking commit is: > > commit 30982be4e5019684e1772dd9170aaa53f5a8e894 > Author: Peter Eisentraut <peter_e@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.
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?