Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 51D90635979; Tue, 23 Feb 2010 21:56:49 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 91464-07; Wed, 24 Feb 2010 01:56:30 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-wy0-f174.google.com (mail-wy0-f174.google.com [74.125.82.174]) by mail.postgresql.org (Postfix) with ESMTP id D9DFD635784; Tue, 23 Feb 2010 21:56:37 -0400 (AST) Received: by wya21 with SMTP id 21so929169wya.19 for ; Tue, 23 Feb 2010 17:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0WVpNhv2yV32JKnbFZqmbptPxcOtSb3WY7FYl0Kheis=; b=KXQbi7FUA7VfxauUnt34IH6OEu2yf4PEyuaXTgqnhFR2xBzh1X1+qPWYHgKdW/fJCv iTd8UrH4c5kE/cwuAvSAGmxwbku0M4V4D3wdGoEqrChiHg3iblz9+6EzMnXyWlGJgnHq jf1xLDxi0PQkpT1iFl10KiG13ZRXzMjZZzbHE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=u06VWhU9IZuJUz0prnCwh9dk4mSd0KJg4Ij+KPySNPwSdZKO7wp+8EPNql4GGICz+G yqzgE9pobTZVLEtIDUZjyQB7QU7jAIMFLq30KZTQ8LLIs17wqJu0Ev3qRXAE04Y/4M3m z5GEdPXYdWPym4j4UKdOLjjUOa38cqt+N2qBU= MIME-Version: 1.0 Received: by 10.216.88.80 with SMTP id z58mr1551462wee.116.1266976595758; Tue, 23 Feb 2010 17:56:35 -0800 (PST) In-Reply-To: <03d401cab4b0$8cd6c690$a68453b0$@com> References: <1266922981.24312.217.camel@coyote> <03d401cab4b0$8cd6c690$a68453b0$@com> Date: Wed, 24 Feb 2010 09:56:35 +0800 Message-ID: Subject: Re: how do I do dump and restore without bugging with constraint? From: "Net Tree Inc." To: =?ISO-8859-1?Q?I=F1igo_Martinez_Lasala?= Cc: pgsql-admin@postgresql.org, pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary=0016e6d464cfee4e7804804ef96d X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.598 tagged_above=-10 required=5 tests=BAYES_00=-2.599, HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 201002/186 X-Sequence-Number: 33789 --0016e6d464cfee4e7804804ef96d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Quote: "However if you have to modify table definitions, you will probably not be able to import data in that new schema and it will be necesary to look for a new strategy." For schema, are we talking about attribute columns (structure of table) and "table definitions" referraled you talking about things like "data types"?I= f error came out during restore are related with table definitions then it's probably no help?I see something related with Deferrable and Initially deferrable that seems like something could avoid constraints when dumping and restore, but it has to modify the table or re-create all of them to hav= e such option (maybe is what you referraled "table definitions"). Is it what it can be use for to avoid during dumping and restoring? DEFERRABLE NOT DEFERRABLE This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command. Checking of constraints that are deferrable can be postponed until the end of the transaction (using the *SET CONSTRAINTS*command). NOT DEFERRABLE is the default. Only foreign key constraints currently accept this clause. All other constraint types are not deferrable. INITIALLY IMMEDIATE INITIALLY DEFERRED If a constraint is deferrable, this clause specifies the default time to check the constraint. If the constraint is INITIALLY IMMEDIATE, it is checked after each statement. This is the default. If the constraint is INITIALLY DEFERRED, it is checked only at the end of the transaction. The constraint check time can be altered with the *SET CONSTRAINTS*command. On Wed, Feb 24, 2010 at 1:49 AM, I=F1igo Martinez Lasala < imartinez@vectorsf.com> wrote: > To avoid contraints you have to use =96disable-triggers flag during > restore. That is done in step 5. > > > > In order to modify schema you have to locate what is failing. So, first > restore old schema without modifications in your new database, watch for > errors and fix them. > > For example: > > psql -U username -d database -h server_destination -f schema.sql > 2>import_error.log > > > > You=92ll find all import errors in import_error.log. Since you are only g= oing > to launch an schema definition, It will only take a few seconds, so test = all > you need. > > After locating errors, open schema.sql with your favorite editor and fix > them. There are minor changes between postgresql versions and you=92ll > probably have no problems in order to fix them, or ask here if you have m= any > problems. > > Once fixed, you will have your new modified_schema.sql and you can procee= d > with steps 4 and 5. > > > > Obviously, if errors are related to indexes, functions, broken > dependencies, etc without touching table definitions, everything will go > well. However if you have to modify table definitions, you will probably = not > be able to import data in that new schema and it will be necesary to look > for a new strategy. > > > > *De:* Net Tree Inc. [mailto:nettreeinc@gmail.com] > *Enviado el:* martes, 23 de febrero de 2010 17:36 > *Para:* I=F1igo Martinez Lasala > *CC:* pgsql-admin@postgresql.org; pgsql-general@postgresql.org > *Asunto:* Re: [ADMIN] how do I do dump and restore without bugging with > constraint? > > > > Thanks. Is it by doing these steps I can avoid constrain restriction? for > step 3, how should I modify the schema? and which schema? the target DB's > schema that I am trying to dump the schema and data in? But this is the > problem, I am not sure whats different between the two schema's, there ar= e > just too many tables to check. What's your tips? > > Steven > > On Tue, Feb 23, 2010 at 7:03 PM, I=F1igo Martinez Lasala < > imartinez@vectorsf.com> wrote: > > Using pg_dump from your new host (that is, newer version) > > 1- Dump schema. > pg_dump -h server_source -U username -s -Fp -f schema.sql database > > 2- Dump data only. > pg_dump -h server_source -U username -a -Fc -f data.dmp database > > 3- Modify schema. > > 4- Restore schema in new host. > psql -U username -d database -h server_destination -f modified_schema.sql > > 5- Restore data disabling triggers > pg_restore -h server_destination -U username -d database --disable-trigge= rs > -a data.dmp > > > > > -----Original Message----- > *From*: Net Tree Inc. > > > *To*: pgsql-admin@postgresql.org, pgsql-general@postgresql.org > *Subject*: [ADMIN] how do I do dump and restore without bugging with > constraint? > *Date*: Tue, 23 Feb 2010 12:50:27 +0800 > > Hi all, > > I am dumping both schema and data from old database to new one. The new > database schema is somehow contain slightly different schema then the old > one. When I do restore it shown alot errors related with constraints. How > can I dump and to restore from old to new without dealing with constraint > and just forces data dump to where it suppose to belong? > > > > > > > > > > > > -- > --------------------------------------- > Steven Huang > --=20 --------------------------------------- Steven Huang --0016e6d464cfee4e7804804ef96d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Quote: "However if you have t= o modify table definitions, you will probably not be able to import data in that new schem= a and it will be necesary to look for a new strategy."
For schema, are we talking about attribute columns (structure of= table) and "table definitions" referraled you talking about thin= gs like "data types"?
If error came out during restore are related with table definitions the= n it's probably no help?
I see something related with Deferrab= le and Initially deferrable that seems like something could avoid constrain= ts when dumping and restore, but it has to modify the table or re-create al= l of them to have such option (maybe is what you referraled "table def= initions"). Is it what it can be use for to avoid during dumping and r= estoring?



DEFERRABLE
NOT DEFERRABLE

This controls whether the constraint can be deferred. A constraint that is not deferrable will be checked immediately after every command. Checking of constraints that are deferrable can be postponed until the end of the transaction (using the SET CONSTRAINTS command). = NOT DEFERRABLE is the default. Only foreign key constraints currently accept this clause. All other constraint types are not deferrable.

= INITIALLY IMMEDIATE
INITIALLY DEFERRED

If a constraint is deferrable, this clause specifies the default time to check the constraint. If the constraint is INITIAL= LY IMMEDIATE, it is checked after each statement. This is the de= fault. If the constraint is INITIALLY DEFERRED= , it is checked only at the end of the transaction. The constra= int check time can be altered with the SET CONSTRAINTS= command.



On Wed, Feb 24, 2010 at 1:49 A= M, I=F1igo Martinez Lasala <imartinez@vectorsf.com> wrote:

To avoid contraints you have to use =96disable-triggers flag during restore. T= hat is done in step 5.

=A0

In order to modify schema you have to locate what is failing. So, first restor= e old schema without modifications in your new database, watch for errors and fix them.

For example:

psql -U username -d database -h server_destination -f schema.sql 2>import_error.log

=A0

You=92ll find all import errors in import_error.log. Since you are only going to lau= nch an schema definition, It will only take a few seconds, so test all you need= .

After locating errors, open schema.sql with your favorite editor and fix them. Th= ere are minor changes between postgresql versions and you=92ll probably have no problems in order to fix them, or ask here if you have many problems.

Once fixed, you will have your new modified_schema.sql and you can proceed with steps 4 and 5.

=A0

Obviously, if errors are related to indexes, functions, broken dependencies, etc witho= ut touching table definitions, everything will go well. However if you have to modify t= able definitions, you will probably not be able to import data in that new schem= a and it will be necesary to look for a new strategy.

=A0

De: Net Tree Inc. [mailto:nettreein= c@gmail.com]
Enviado el: martes, 23 de febrero de 2010 17:36
Para: I=F1igo Martinez Lasala
CC: = pgsql-admin@postgresql.org; pgsql-general@postgresql.org
Asunto: Re: [ADMIN] how do I do dump and restore without bugging wit= h constraint?

=A0

Thanks. Is it by doin= g these steps I can avoid constrain restriction? for step 3, how should I modify th= e schema? and which schema? the target DB's schema that I am trying to du= mp the schema and data in? But this is the problem, I am not sure whats different between the two schema's, there are just too many tables to check. What= 's your tips?

Steven

On Tue, Feb 23, 2010 at 7:03 PM, I=F1igo Martinez La= sala <imarti= nez@vectorsf.com> wrote:

Using pg_dump from your new host (that is, newer ver= sion)

1- Dump schema.
pg_dump -h server_source -U username -s -Fp -f schema.sql database

2- Dump data only.
pg_dump -h server_source -U username -a -Fc -f data.dmp database

3- Modify schema.

4- Restore schema in new host.
psql -U username -d database -h server_destination -f modified_schema.sql
5- Restore data disabling triggers
pg_restore -h server_destination -U username -d database --disable-triggers= -a data.dmp




-----Original Message-----
From: Net Tree Inc. <nettreeinc@gmail.com><= br> To: = pgsql-admin@postgresql.org, pgsql-gen= eral@postgresql.org
Subject: [ADMIN] how do I do dump and restore without bugging with constraint?
Date: Tue, 23 Feb 2010 12:50:27 +0800

Hi all,

I am dumping both schema and data from old database to new one. The new database schema is somehow contain slightly different schema then the old o= ne. When I do restore it shown alot errors related with constraints. How can I = dump and to restore from old to new without dealing with constraint and just for= ces data dump to where it suppose to belong?=A0











--
---------------------------------------
Steven Huang




--
-----------------------= ----------------
Steven Huang
--0016e6d464cfee4e7804804ef96d--