Re: dump difference between 9.3 and master after upgrade
От | Andrew Dunstan |
---|---|
Тема | Re: dump difference between 9.3 and master after upgrade |
Дата | |
Msg-id | 51C6011B.3070807@dunslane.net обсуждение исходный текст |
Ответ на | Re: dump difference between 9.3 and master after upgrade (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: dump difference between 9.3 and master after upgrade
|
Список | pgsql-hackers |
On 06/20/2013 11:16 AM, I wrote: > > On 06/20/2013 10:43 AM, Robert Haas wrote: >> On Tue, Jun 18, 2013 at 12:18 PM, Andrew Dunstan >> <andrew@dunslane.net> wrote: >>> As I was updating my cross version upgrade tester to include support >>> for the >>> 9.3 branch, I noted this dump difference between the dump of the >>> original >>> 9.3 database and the dump of the converted database, which looks >>> odd. Is it >>> correct? >> It looks sketchy to me, but I'm not sure exactly what you're comparing. > > > Essentially, cross version upgrade testing runs pg_dumpall from the > new version on the old cluster, runs pg_upgrade, and then runs > pg_dumpall on the upgraded cluster, and compares the two outputs. This > is what we get when the new version is HEAD and the old version is 9.3. > > The reason this hasn't been caught by the standard same-version > upgrade tests is that this module uses a more extensive cluster, which > has had not only the core regression tests run but also all the > contrib and pl regression tests, and this problem seems to be exposed > by the postgres_fdw tests. > > At first glance to me like pg_dump in binary-upgrade mode is not > suppressing something that it should be suppressing. > Yeah, after examination I don't see why we should output anything for dropped columns of a foreign table in binary upgrade mode. This looks to me like it's been a bug back to 9.1 where we introduced foreign tables. I think something like the attached should fix it, although I'm not sure if that's the right place for the fix. cheers andrew
Вложения
В списке pgsql-hackers по дате отправления: