Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall
Дата
Msg-id CAJrrPGfnRVV=gTZ8kRSUWWcFngnhdn+a_V2hwT-TWi6mMsDGOg@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Ответы Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Список pgsql-hackers
Дерево обсуждения


On Wed, Mar 29, 2017 at 11:04 PM, Andreas Karlsson <andreas@proxel.se> wrote:
On 03/29/2017 05:43 AM, Haribabu Kommi wrote:
> Updated patch attached.

I get a test failure in the pg_upgrade tests, but I do not have time right now to investigate.

The failing test is "Restoring database schemas in the new cluster".

Thanks for test.

I found the reason for failure.

Before this refactor patch, in case of --binary-upgrade, the pg_dumpall
dumps all the global objects and also the database objects. These objects
will be restored first during the preparation of the new cluster and later
each individual database is restored.

Because of the refactoring of the database objects, currently as part of
globals dump with --binary-upgrade, no database objects gets dumped.
During restore no databases are created. so while restoring individual
database, it leads to failure as it not able to connect to the target database.

Currently I marked the patch in the commitfest as "returned with feedback"
as in the current situation, this needs some analysis in handling database
objects in --binary-upgrade mode.

Regards,
Hari Babu
Fujitsu Australia

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: [BUGS] Bug in Physical Replication Slots (at least9.5)?
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PATCH: Batch/pipelining support for libpq