Postgres Pro
Downloads
Home   >   mailing lists

Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall - Mailing list pgsql-hackers

From Haribabu Kommi
Subject Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall
Date
Msg-id CAJrrPGfnRVV=gTZ8kRSUWWcFngnhdn+a_V2hwT-TWi6mMsDGOg@mail.gmail.com
Whole thread Raw
In response to [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall  (Haribabu Kommi <kommi.haribabu@gmail.com>)
Responses Re: Refactor handling of database attributes betweenpg_dump and pg_dumpall  (Haribabu Kommi <kommi.haribabu@gmail.com>)
List pgsql-hackers
Tree view


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 by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: [BUGS] Bug in Physical Replication Slots (at least9.5)?
Next
From: Michael Paquier
Date:
Subject: Re: PATCH: Batch/pipelining support for libpq