pg_upgade vs config

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
HANDLERpublic.blhandler;   +   +   +--   +-- Name: ACCESS METHOD bloom; Type: COMMENT; Schema: -; Owner:   +--   +
+COMMENTON 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