Re: BUG #16732: pg_dump creates broken backups - Mailing list pgsql-bugs

From Zsolt Ero
Subject Re: BUG #16732: pg_dump creates broken backups
Date
Msg-id CAKw-smBUUTYNJQJ21+LEOEnCqPLWfX0XVixA3eHBcAT3Nh33pQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16732: pg_dump creates broken backups  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: BUG #16732: pg_dump creates broken backups
List pgsql-bugs
Why do you do that?  It seems much easier to produce a complete dump,
then obtain the --list from it, do "grep -v" of the TABLE DATA element
for that table, then give that file to pg_restore.  It would restore
everything in the right order, including that table's definition, but
excluding that table's data.

Can you help me how can I do this?

Here is what I was doing before, which triggered the bug:

pg_restore --schema-only --format=custom --single-transaction $BACKUP_FILE

pg_restore --list $BACKUP_FILE > dump_list.full
grep -v "public events_map" dump_list.full > dump_list.main

pg_restore --data-only --format=custom --use-list=dump_list.main --jobs=4 $BACKUP_FILE

If it's not clear, I'd like to restore the original database 1:1, but without the data included in the "events_map" table. I mean the results should be the same as if I'd run truncate after import.

Zsolt

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16730: Create table like with inheritance and self referencing index
Next
From: Susanne & Udo Krause
Date:
Subject: lc_collate mess