Re: BUG #13444: psql can't recover a pg_dump.
От | Jeff Janes |
---|---|
Тема | Re: BUG #13444: psql can't recover a pg_dump. |
Дата | |
Msg-id | CAMkU=1znatVLsyNb9nMJXNqj3yR-sQ3sXksbfPK_27Ka+5KEOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #13444: psql can't recover a pg_dump. (Sergi Casbas <sergi.casbas@iris.cat>) |
Ответы |
Re: BUG #13444: psql can't recover a pg_dump.
|
Список | pgsql-bugs |
On Tue, Jun 16, 2015 at 1:40 AM, Sergi Casbas <sergi.casbas@iris.cat> wrote: > Hi Jeff, > > This example is made by hand, but reproduces a situation made with pg_dump > 9.4.4. on a 9.4.1 server > > The dump belongs to a project with more than 800 objects, but is a private > project and i'm not authorized to send it to you, this is why I create i > dummy dump that recreates the situation. > Hi Sergi, It is understandable that you can't share the whole schema, but unfortunately that doesn't give us very much to work with. The thing that needs to be fixed is how the original dump gets made, not how it replays. So a reproducible test case would have to be something that reproduces a broken dump, rather than something which is itself a broken dump. What happens if you dump the whole schema (without data), manually fix the dump so that it can be restored, restore it to a test instance, and then dump from that instance? Is that dump still broken? If it is still broken, that suggests a bug in pg_dump. Next thing I would try is to delete seemingly-irrelevant objects in a controlled manner, either until the you have something small enough you can share it, or until the problem goes away. The last object deleted before the problem went away must be triggering the bug. If it not still broken after a dump-manual repair-reload cycle, then that sounds more like some form of corruption in your existing database, rather than a bug in the software. Cheers, Jeff
В списке pgsql-bugs по дате отправления: