From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Zsolt Ero <zsolt(dot)ero(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16732: pg_dump creates broken backups |
Date: | 2020-11-20 16:28:33 |
Message-ID: | 1303022.1605889713@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Zsolt Ero <zsolt(dot)ero(at)gmail(dot)com> writes:
> Sorry this is not so general, I over-simplified the example. The key is
> --use-list (with possibly --jobs)
> What I've double checked is that the following breaks it consistently:
> pg_restore --schema-only --dbname=app --format=custom --single-transaction
> $BACKUP_FILE
> pg_restore --list $BACKUP_FILE > dump_list.full
> pg_restore --data-only --dbname=app --format=custom
> --use-list=dump_list.full --jobs=4 $BACKUP_FILE
I suspect actually the problem has more to do with having split the
restore into --schema-only and --data-only steps. That forces
pg_restore to create the FK constraints before it's loaded the
data, and in certain cases such as circular FK relationships,
there will be no safe restore order for the data.
However, that's all just speculation since you haven't shown us
a reproducible case.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | James Coleman | 2020-11-20 19:51:14 | Re: segfault with incremental sort |
Previous Message | Magnus Hagander | 2020-11-20 15:16:29 | Re: Don't do that: Changing the working directory in a plpython function |