Re: pg_upgade vs config - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_upgade vs config
Date
Msg-id 29311.1475430814@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_upgade vs config  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: pg_upgade vs config  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
> On 10/02/2016 09:50 AM, Michael Paquier wrote:
>> On Sun, Oct 2, 2016 at 10:40 PM, Andrew Dunstan <andrew@dunslane.net> wrote:
>>> 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.

>> 562f06f3 has addressed this issue 3 months ago, and there is a test in
>> src/test/modules/test_pg_dump.

> So then why are the pre-upgrade and post-upgrade dumps different?

Because pg_dump with --binary-upgrade neglects to emit

ALTER EXTENSION bloom ADD ACCESS METHOD bloom;

which it would need to do in order to make this work right.  The other
small problem is that there is no such ALTER EXTENSION syntax in the
backend.  This is a rather major oversight in the patch that added DDL
support for access methods, if you ask me.

(Also, I didn't look at what test_pg_dump is testing, but I bet it
isn't attempting to cover --binary-upgrade behavior.)
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_upgade vs config
Next
From: Andrew Dunstan
Date:
Subject: Re: pg_upgade vs config