BUG #13576: a weird behavior of pg_restore command
От | nao-anzai@xc.jp.nec.com |
---|---|
Тема | BUG #13576: a weird behavior of pg_restore command |
Дата | |
Msg-id | 20150817082443.1670.1103@wrigleys.postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #13576: a weird behavior of pg_restore command
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 13576 Logged by: Naoya Anzai Email address: nao-anzai@xc.jp.nec.com PostgreSQL version: 9.5alpha2 Operating system: Linux Description: Hi hackers, I found a little bit weird behavior of pg_restore command when specified --no-data-for-failed-tables and -c options. Following is a script for reproducing that cases. --- # SQL psql template1 <<EOF drop database if exists db_test; create database db_test; \c db_test begin; drop table if exists t1; drop table if exists t2; create table t1 as select 1::integer as id; create table t2 as select * from t1; commit; EOF # UNIX commands pg_dump -Fc -f db_test.dmp db_test # SQL psql db_test <<EOF begin; drop table if exists t1; drop table if exists t2; commit; EOF # UNIX commands pg_restore -v --no-data-for-failed-tables -c db_test.dmp -d db_test # SQL psql db_test <<EOF begin; select count(*) as t1_count from t1; select count(*) as t2_count from t2; commit; EOF --- The result is following. t1_count ---------- 0 (1 row) t2_count ---------- 1 (1 row) I think this result is absolutely weird because both of creation commands are ok but t2 data is restored, and somehow t1 data is not restored. PostgreSQL document of --no-data-for-failed-tables is following. --- By default, table data is restored even if the creation command for the table failed (e.g., because it already exists). With this option, data for such a table is skipped. --- In this case, both of creation command didn't failed. So t1 data should be restored even if --no-data-for-failed-tables option is specified. I have analyzed pg_restore command, and modified like following. 1. Any DROP queries are currently in PROCESSING stage.To fix this behavior, at least, DROP queries and others have to be split into two stages. Tentatively, I moved Any DROP queries from PROCESSING stage to INITIALIZING stage. And I have added lastErrorStage check in noDataForFailedTables check. 2. noDataForFailedTables check is currently using AH->lastErrorTE, this doesn't work fine because pre TOC error is overwritten by current TOC error. Each TOC should have each own error status, so I removed AH->lastErrorTE, I added _tocEntry->wasError instead of that. 3. and fixed a japanese word typo of pg_restore --help. I attached a patch. Would anyone confirm this? Regards, Naoya --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-anzai@xc.jp.nec.com ---
В списке pgsql-bugs по дате отправления: