Re: BUG #13576: a weird behavior of pg_restore command - Mailing list pgsql-bugs
From | Naoya Anzai |
---|---|
Subject | Re: BUG #13576: a weird behavior of pg_restore command |
Date | |
Msg-id | 116262CF971C844FB6E793F8809B51C6EDDCFB@BPXM02GP.gisp.nec.co.jp Whole thread Raw |
In response to | BUG #13576: a weird behavior of pg_restore command (nao-anzai@xc.jp.nec.com) |
List | pgsql-bugs |
Sorry, I forgot the attached. Regards, Naoya --- Naoya Anzai Engineering Department NEC Solution Inovetors, Ltd. E-Mail: nao-anzai@xc.jp.nec.com --- > -----Original Message----- > From: pgsql-bugs-owner@postgresql.org > [mailto:pgsql-bugs-owner@postgresql.org] On Behalf Of > nao-anzai@xc.jp.nec.com > Sent: Monday, August 17, 2015 5:25 PM > To: pgsql-bugs@postgresql.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@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 > --- > > > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs
Attachment
pgsql-bugs by date: