I'm working on updating and making production ready my experimental
cross version pg_upgrade testing module for the buildfarm. A couple of
things have emerged that are of concern. This module does a much more
complete test that our normal test for pg_upgrade, which only checks
upgrading the standard regression database. This tests all the databases
the buildfarm creates for testing, including those made by modules in
contrib.
The biggest issue is this: the upgrade fails completely on
ltree-plpython and hstore-plpython, presumably because these modules
rely on the plpython module being loaded first. pg_upgrade rather
simple-mindedly calls LOAD on the object library to test if it's usable.
It's a bit embarrassing that we can't upgrade a database using one of
our own modules. At the very least we should hard-code a way around this
(e.g. have it load the relevant plpython module first), but more
generally I think we need a way to tell pg_upgrade that module X relies
on module Y. In the past ISTR we've said we don't support having
dependencies between loadable modules, but that ship now seems to have
sailed.
Second, we get an unexpected difference between the pre-upgrade and
post-upgrade dumps for the bloom module:
--- /home/bf/bfr/root/upgrade/HEAD/origin-REL9_6_STABLE.sql
2016-10-02 09:16:03.298341639 -0400
+++
/home/bf/bfr/root/upgrade/HEAD/converted-REL9_6_STABLE-to-HEAD.sql
2016-10-02 09:16:54.889343991 -0400
@@ -7413,6 +7413,20 @@
COMMENT ON EXTENSION bloom IS 'bloom access method - signature
file based index';
+--
+-- Name: bloom; Type: ACCESS METHOD; Schema: -; Owner:
+--
+
+CREATE ACCESS METHOD bloom TYPE INDEX HANDLER public.blhandler;
+
+
+--
+-- Name: ACCESS METHOD bloom; Type: COMMENT; Schema: -; Owner:
+--
+
+COMMENT ON ACCESS METHOD bloom IS 'bloom index access method';
+
+
SET search_path = public, pg_catalog;
SET default_tablespace = '';
It looks like we have some work to do to teach pg_dump about handling
access methods in extensions. This doesn't look quite as bad as the
first issue, but it's a pity 9.6 escaped into the wild with this issue.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
