Re: BUG #13576: a weird behavior of pg_restore command

Sorry, I forgot the attached.

Regards,

Naoya

---
Naoya Anzai
Engineering Department
NEC Solution Inovetors, Ltd.
E-Mail: nao-anzai(at)xc(dot)jp(dot)nec(dot)com
---

> -----Original Message-----
> From: pgsql-bugs-owner(at)postgresql(dot)org
> [mailto:pgsql-bugs-owner(at)postgresql(dot)org] On Behalf Of
> nao-anzai(at)xc(dot)jp(dot)nec(dot)com
> Sent: Monday, August 17, 2015 5:25 PM
> To: pgsql-bugs(at)postgresql(dot)org
> Subject: [BUGS] BUG #13576: a weird behavior of pg_restore command
>
> The following bug has been logged on the website:
>
> Bug reference: 13576
> Logged by: Naoya Anzai
> Email address: nao-anzai(at)xc(dot)jp(dot)nec(dot)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(at)xc(dot)jp(dot)nec(dot)com
> ---
>
>
>
> --
> Sent via pgsql-bugs mailing list (pgsql-bugs(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-bugs