BUG #13576: a weird behavior of pg_restore command - Mailing list pgsql-bugs

From nao-anzai@xc.jp.nec.com
Subject BUG #13576: a weird behavior of pg_restore command
Date
Msg-id 20150817082443.1670.1103@wrigleys.postgresql.org
Whole thread Raw
Responses Re: BUG #13576: a weird behavior of pg_restore command  (Naoya Anzai <nao-anzai@xc.jp.nec.com>)
List 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 by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: BUG #13575: invalid memory request size while storing call arguments into local variables
Next
From: Naoya Anzai
Date:
Subject: Re: BUG #13576: a weird behavior of pg_restore command