'COPY' Statement

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF318EDElzargrantc ou_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Dear all,

I just had a thought, another one. Please the guys who have the powerful kn=
owledge I need your help ;-)

Let's suppose
I have Three DB servers ,physical servers - let's call them:

* Original_DB01

* New_DB02

* Third_DB03

1 - Let's suppose I have a PostgreSQL on 'Original_DB01' server with a Data=
Base of 162GB in size.
2 - Let's suppose I buy a new server 'New_DB02' - all singing all dancing c=
ool server, RAID10, 25GB RAM, 64Bit etc.
3 - Let's suppose I backup the old server with pg_dump to a file "pg_dump_o=
riginal_DB01"
4 - Let's also suppose I backup the schema only from 'Original_DB01'and res=
tore it to 'Third_DB03'.
5 - Straight after I backup the schema, I stop PostgreSQL on 'Original_DB01=
'.
6 - Then I restore the schema to 'Third_DB03' and point the application to =
it.
7 - Let's suppose the application can create tables and can start using the=
database on 'Third_DB03' and adding new data.
8 - Let's suppose I restore the FULL pg_dump file "pg_dump_original_DB01" =
to 'New_DB02'
9 - Once the pg_dump has been restored to 'New_DB02' I can then point the a=
pplication to it and data will be added to it straight away.

Question:
10 - Can I use 'COPY' statement to transfer the data from 'Third_DB03' to '=
New_DB02' without 'WIPING' or Deleting the existing data?
I want to merge the DATA from 'Third_DB03' to 'New_DB02' without deleting t=
he Database or the existing data on the existing database.

Let me explain the Idea behind this craziness.
I am using 'Third_DB03' because the amount of data to be transferred from i=
t, will be minimum, and easy to and quick to 'COPY'

This application has two part components (Data and Alarms)
We can get the data back in a very hard way, but without the data being in =
the database we can't generate alarms.

I would very much appreciate all your help on this idea, please.
I would be very glad and grateful for any comments and improvements on this=
idea, picking the holes etc.

Thank you very much in advance

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk<http://www.grant.co.uk/>

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email
CONFIDENTIALITY: The information in this e-mail and any attachments is conf=
idential. It is intended only for the named recipients(s). If you are not t=
he named recipient please notify the sender immediately and do not disclose=
the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain viruses w=
hich could damage your own computer system. Whilst Grant Instruments (Cambr=
idge) Ltd has taken every reasonable precaution to minimise this risk, we c=
annot accept liability for any damage which you sustain as a result of soft=
ware viruses. You should therefore carry out your own virus checks before o=
pening the attachment(s).

OpenXML: For information about the OpenXML file format in use within Grant =
Instruments please visit our website<http://www.grant.co.uk/Support/openxml=
..html>

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF318EDElzargrantc ou_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:m=3D"http://schemas.m=
icrosoft.com/office/2004/12/omml" xmlns:o=3D"urn:schemas-microsoft-com:offi=
ce:office" xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:w=3D"urn:schemas=
-microsoft-com:office:word"><head><META content=3D"text/html; charset=3Dus-=
ascii" http-equiv=3D"Content-Type">
<META content=3D"text/html; charset=3Dus-ascii" http-equiv=3D"Content-Type"=
>

<meta content=3D"text/html; charset=3Dus-ascii" http-equiv=3DContent-Type>
<meta content=3D"Microsoft Word 12 (filtered medium)" name=3DGenerator>
<style>

</style>

</head><BODY>
<DIV STYLE=3D"FONT-SIZE: 9pt; FONT-FAMILY: Courier New">
<DIV>
<DIV>

<div class=3DSection1>

Dear all,<o:p></o:p>

<o:p> </o:p>

I just had a thought, another one. Please the guys who=
have
the powerful knowledge I need your help ;-)<o:p></o:p>

<o:p> </o:p>

Let’s suppose<o:p></o:p>

I have Three DB servers ,physical servers –=
; let’s
call them: <o:p></o:p>

<![if !supportLists]>·&=
nbsp;
<![endif]>Original_DB01<o:p></o:p>

<![if !supportLists]>·&=
nbsp;
<![endif]>New_DB02<o:p></o:p>

<![if !supportLists]>·&=
nbsp;
<![endif]>Third_DB03<o:p></o:p>

<o:p> </o:p>

1 – Let’s suppose I have a PostgreSQL on &=
#8216;Original_DB01’
server with a Data Base of 162GB in size.<o:p></o:p>

2 – Let’s suppose I buy a new server ̵=
6;New_DB02’
- all singing all dancing cool server, RAID10, 25GB RAM, 64Bit etc.<o:p></o=
:p>

3 – Let’s suppose I backup the old server =
with
pg_dump to a file “pg_dump_original_DB01”<o:p></o:p>

4 – Let’s also suppose I backup the schema=
only
from ‘Original_DB01’and restore it to ‘Third_DB03’.=
<o:p></o:p>

5 – Straight after I backup the schema, I stop P=
ostgreSQL
on ‘Original_DB01’.<o:p></o:p>

6 – Then I restore the schema to ‘Third_DB=
03’
and point the application to it.<o:p></o:p>

7 – Let’s suppose the application can crea=
te
tables and can start using the database on ‘Third_DB03’ and add=
ing
new data.<o:p></o:p>

8 – Let’s suppose I restore the FULL =
;pg_dump
file “pg_dump_original_DB01” to ‘New_DB02’<o:p></o:=
p>

9 – Once the pg_dump has been restored to ‘=
;New_DB02’
I can then point the application to it and data will be added to it straigh=
t
away.<o:p></o:p>

<o:p> </o:p>

Question:<o:p></o:p>

10 – Can I use ‘COPY’ statement to
transfer the data from ‘Third_DB03’ to ‘New_DB02’ w=
ithout
‘WIPING’ or Deleting the existing data?<o:p></o:p>

I want to merge the DATA from ‘Third_DB03’=
to ‘New_DB02’
without deleting the Database or the existing data on the existing database=
..<o:p></o:p>

<o:p> </o:p>

Let me explain the Idea behind this craziness.<o:p></o=
:p>

I am using ‘Third_DB03’ because the amount=
of
data to be transferred from it, will be minimum, and easy to and quick to &=
#8216;COPY’<o:p></o:p>

<o:p> </o:p>

This application has two part components (Data and Ala=
rms) <o:p></o:p>

We can get the data back in a very hard way, but witho=
ut the
data being in the database we can’t generate alarms.<o:p></o:p>

<o:p> </o:p>

I would very much appreciate all your help on this ide=
a,
please.<o:p></o:p>

I would be very glad and grateful for any comments and
improvements on this idea, picking the holes etc.<o:p></o:p>

<o:p> </o:p>

Thank you very much in advance<o:p></o:p>

<o:p> </o:p>

Renato<o:p></o:p>

<o:p> </o:p>

<o:p> </o:p>

<o:p> </o:p>

</div>

</DIV>
<DIV> </DIV>
<DIV>Renato=
Oliveira Systems Administrator e-mail: renato.oliveira [at] grant.co.uk</=
FONT></DIV>
<DIV></FONT=
> </DIV>
<DIV>Tel: +=
44 (0)1763 260811 Fax: +44 (0)1763 262410 <A HREF=3D"http://www.grant=
..co.uk/">www.grant.co.uk</A></DIV>
<DIV></FONT=
> </DIV>
<DIV>Grant =
Instruments (Cambridge) Ltd Company registered in England, re=
gistration number 658133 Registered office address: 29 Stat=
ion Road, Shepreth, CAMBS SG8 6GB UK</DIV>
<DIV></FONT=
></F=
ONT> </DIV>
<DIV></FONT=
></DIV>
<DIV></FONT=
> </DIV>
<DIV></FONT=
></DIV>
<DIV> </DIV>
<DIV></FONT=
></DIV>
<DIV> </DIV> </DIV>
<DIV>
 
P Please consider the environ=
ment before printing this email</DIV>
<DIV>CONFIDENTIALITY: The =
information in this e-mail and any attachments is confidential. It is inten=
ded only for the named recipients(s). If you are not the named recipient pl=
ease notify the sender immediately and do not disclose the contents to anot=
her person or take copies. </DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV>VIRUSES: The contents=
of this e-mail or attachment(s) may contain viruses which could damage you=
r own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken e=
very reasonable precaution to minimise this risk, we cannot accept liabilit=
y for any damage which you sustain as a result of software viruses. You sho=
uld therefore carry out your own virus checks before opening the attachment=
(s).</DIV>
<DIV> </DIV>
<DIV></DIV>
<DIV>OpenXML: For informat=
ion about the OpenXML file format in use within Grant Instruments please vi=
sit our <A HREF=3D"http://www.grant.co.uk/Support/openxml.html">website</A>=
</DIV></DIV></BODY></HTML>

--_000_7965A9DCF12CC14984420BCC37B1608F25ABF318EDElzargrantc ou_--

--=-JZw98idRUCKZ4xHbFg7j
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I think it depends of your datamodel and specifically of your table
constraints.

For example, if you have a table with a pk generated by a sequence, you
will have to deal with it before importing into your New_DB02. But for a
plain log table without constrains you can dump it an import into your
"just loaded" New_DB02 without any problem.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: pgsql-admin [at] postgresql.org <pgsql-admin [at] postgresql.org>
Cc: Steve Fisher <steve.fisher [at] grant.co.uk>
Subject: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:42:19 +0100

Dear all,

I just had a thought, another one. Please the guys who have the powerful
knowledge I need your help ;-)

Let=E2=80=99s suppose

I have Three DB servers ,physical servers =E2=80=93 let=E2=80=99s call t=
hem:

=C2=B7 Original_DB01

=C2=B7 New_DB02

=C2=B7 Third_DB03

1 =E2=80=93 Let=E2=80=99s suppose I have a PostgreSQL on =E2=80=98Origina=
l_DB01=E2=80=99 server with a
Data Base of 162GB in size.

2 =E2=80=93 Let=E2=80=99s suppose I buy a new server =E2=80=98New_DB02=E2=
=80=99 - all singing all
dancing cool server, RAID10, 25GB RAM, 64Bit etc.

3 =E2=80=93 Let=E2=80=99s suppose I backup the old server with pg_dump to=
a file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D

4 =E2=80=93 Let=E2=80=99s also suppose I backup the schema only from =E2=80=
=98Original_DB01=E2=80=99and
restore it to =E2=80=98Third_DB03=E2=80=99.

5 =E2=80=93 Straight after I backup the schema, I stop PostgreSQL on
=E2=80=98Original_DB01=E2=80=99.

6 =E2=80=93 Then I restore the schema to =E2=80=98Third_DB03=E2=80=99 and=
point the application
to it.

7 =E2=80=93 Let=E2=80=99s suppose the application can create tables and c=
an start using
the database on =E2=80=98Third_DB03=E2=80=99 and adding new data.

8 =E2=80=93 Let=E2=80=99s suppose I restore the FULL pg_dump file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D to =E2=80=98New_DB02=E2=80=99

9 =E2=80=93 Once the pg_dump has been restored to =E2=80=98New_DB02=E2=80=
=99 I can then point
the application to it and data will be added to it straight away.

Question:

10 =E2=80=93 Can I use =E2=80=98COPY=E2=80=99 statement to transfer the d=
ata from =E2=80=98Third_DB03=E2=80=99
to =E2=80=98New_DB02=E2=80=99 without =E2=80=98WIPING=E2=80=99 or Deletin=
g the existing data?

I want to merge the DATA from =E2=80=98Third_DB03=E2=80=99 to =E2=80=98Ne=
w_DB02=E2=80=99 without
deleting the Database or the existing data on the existing database.

Let me explain the Idea behind this craziness.

I am using =E2=80=98Third_DB03=E2=80=99 because the amount of data to be =
transferred
from it, will be minimum, and easy to and quick to =E2=80=98COPY=E2=80=99

This application has two part components (Data and Alarms)

We can get the data back in a very hard way, but without the data being
in the database we can=E2=80=99t generate alarms.

I would very much appreciate all your help on this idea, please.

I would be very glad and grateful for any comments and improvements on
this idea, picking the holes etc.

Thank you very much in advance

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

--=-JZw98idRUCKZ4xHbFg7j
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
I think it depends of your datamodel and specifically of your table constraints. 
 
For example, if you have a table with a pk generated by a sequence, you will have to deal with it before importing into your New_DB02. But for a plain log table without constrains you can dump it an import into your "just loaded" New_DB02 without any problem. 
 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: pgsql-admin [at] postgresql.org <<A HREF="mailto:%22pgsql-admin [at] postgresql.org%22%20%3cpgsql-admin [at] postgresql.org%3e">pgsql-admin [at] postgresql.org</A>> 
Cc: Steve Fisher <<A HREF="mailto:Steve%20Fisher%20%3csteve.fisher [at] grant.co.uk%3e">steve.fisher [at] grant.co.uk</A>> 
Subject: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 08:42:19 +0100 
 
Dear all, 
 
 
 
I just had a thought, another one. Please the guys who have the powerful knowledge I need your help ;-) 
 
 
 
Let’s suppose 
 
I have Three DB servers ,physical servers – let’s call them: 
 
· Original_DB01 
 
· New_DB02 
 
· Third_DB03 
 
 
 
1 – Let’s suppose I have a PostgreSQL on ‘Original_DB01’ server with a Data Base of 162GB in size. 
 
2 – Let’s suppose I buy a new server ‘New_DB02’ - all singing all dancing cool server, RAID10, 25GB RAM, 64Bit etc. 
 
3 – Let’s suppose I backup the old server with pg_dump to a file “pg_dump_original_DB01” 
 
4 – Let’s also suppose I backup the schema only from ‘Original_DB01’and restore it to ‘Third_DB03’. 
 
5 – Straight after I backup the schema, I stop PostgreSQL on ‘Original_DB01’. 
 
6 – Then I restore the schema to ‘Third_DB03’ and point the application to it. 
 
7 – Let’s suppose the application can create tables and can start using the database on ‘Third_DB03’ and adding new data. 
 
8 – Let’s suppose I restore the FULL pg_dump file “pg_dump_original_DB01” to ‘New_DB02’ 
 
9 – Once the pg_dump has been restored to ‘New_DB02’ I can then point the application to it and data will be added to it straight away. 
 
 
 
Question: 
 
10 – Can I use ‘COPY’ statement to transfer the data from ‘Third_DB03’ to ‘New_DB02’ without ‘WIPING’ or Deleting the existing data? 
 
I want to merge the DATA from ‘Third_DB03’ to ‘New_DB02’ without deleting the Database or the existing data on the existing database. 
 
 
 
Let me explain the Idea behind this craziness. 
 
I am using ‘Third_DB03’ because the amount of data to be transferred from it, will be minimum, and easy to and quick to ‘COPY’ 
 
 
 
This application has two part components (Data and Alarms) 
 
We can get the data back in a very hard way, but without the data being in the database we can’t generate alarms. 
 
 
 
I would very much appreciate all your help on this idea, please. 
 
I would be very glad and grateful for any comments and improvements on this idea, picking the holes etc. 
 
 
 
Thank you very much in advance 
 
 
 
Renato 
 
 
 
 
 
 
 
 

Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A>

Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK

 

 

 

 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 

 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A>
 
</BODY>
</HTML>

--=-JZw98idRUCKZ4xHbFg7j--

--=-tIQ7TCSJy17kCxzf/+FS
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Primary Key. :)

A Primary Key is always a constraint, since it cannot be duplicated. For
example, if you have a PK generated by a sequence starting at zero, when
you restore your third database into new server you will have duplicated
values in this column and COPY command will fail.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: I=C3=B1igo Martinez Lasala <imartinez [at] vectorsf.com>
Subject: RE: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:59:34 +0100

=EF=BB=BF
Dear I=C3=B1igo,

Thank you very much. What do you mean by =E2=80=98pk=E2=80=99?

I am sorry.

Thank you very much

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

From: I=C3=B1igo Martinez Lasala [mailto:imartinez [at] vectorsf.com]
Sent: 13 April 2010 08:56
To: Renato Oliveira
Cc: pgsql-admin [at] postgresql.org; Steve Fisher
Subject: Re: [ADMIN] 'COPY' Statement

I think it depends of your datamodel and specifically of your table
constraints.

For example, if you have a table with a pk generated by a sequence, you
will have to deal with it before importing into your New_DB02. But for a
plain log table without constrains you can dump it an import into your
"just loaded" New_DB02 without any problem.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: pgsql-admin [at] postgresql.org <pgsql-admin [at] postgresql.org>
Cc: Steve Fisher <steve.fisher [at] grant.co.uk>
Subject: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:42:19 +0100

Dear all,

I just had a thought, another one. Please the guys who have the powerful
knowledge I need your help ;-)

Let=E2=80=99s suppose

I have Three DB servers ,physical servers =E2=80=93 let=E2=80=99s call t=
hem:

=C2=B7 Original_DB01

=C2=B7 New_DB02

=C2=B7 Third_DB03

1 =E2=80=93 Let=E2=80=99s suppose I have a PostgreSQL on =E2=80=98Origina=
l_DB01=E2=80=99 server with a
Data Base of 162GB in size.

2 =E2=80=93 Let=E2=80=99s suppose I buy a new server =E2=80=98New_DB02=E2=
=80=99 - all singing all
dancing cool server, RAID10, 25GB RAM, 64Bit etc.

3 =E2=80=93 Let=E2=80=99s suppose I backup the old server with pg_dump to=
a file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D

4 =E2=80=93 Let=E2=80=99s also suppose I backup the schema only from =E2=80=
=98Original_DB01=E2=80=99and
restore it to =E2=80=98Third_DB03=E2=80=99.

5 =E2=80=93 Straight after I backup the schema, I stop PostgreSQL on
=E2=80=98Original_DB01=E2=80=99.

6 =E2=80=93 Then I restore the schema to =E2=80=98Third_DB03=E2=80=99 and=
point the application
to it.

7 =E2=80=93 Let=E2=80=99s suppose the application can create tables and c=
an start using
the database on =E2=80=98Third_DB03=E2=80=99 and adding new data.

8 =E2=80=93 Let=E2=80=99s suppose I restore the FULL pg_dump file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D to =E2=80=98New_DB02=E2=80=99

9 =E2=80=93 Once the pg_dump has been restored to =E2=80=98New_DB02=E2=80=
=99 I can then point
the application to it and data will be added to it straight away.

Question:

10 =E2=80=93 Can I use =E2=80=98COPY=E2=80=99 statement to transfer the d=
ata from =E2=80=98Third_DB03=E2=80=99
to =E2=80=98New_DB02=E2=80=99 without =E2=80=98WIPING=E2=80=99 or Deletin=
g the existing data?

I want to merge the DATA from =E2=80=98Third_DB03=E2=80=99 to =E2=80=98Ne=
w_DB02=E2=80=99 without
deleting the Database or the existing data on the existing database.

Let me explain the Idea behind this craziness.

I am using =E2=80=98Third_DB03=E2=80=99 because the amount of data to be =
transferred
from it, will be minimum, and easy to and quick to =E2=80=98COPY=E2=80=99

This application has two part components (Data and Alarms)

We can get the data back in a very hard way, but without the data being
in the database we can=E2=80=99t generate alarms.

I would very much appreciate all your help on this idea, please.

I would be very glad and grateful for any comments and improvements on
this idea, picking the holes etc.

Thank you very much in advance

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

--=-tIQ7TCSJy17kCxzf/+FS
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
Primary Key. :) 
 
A Primary Key is always a constraint, since it cannot be duplicated. For example, if you have a PK generated by a sequence starting at zero, when you restore your third database into new server you will have duplicated values in this column and COPY command will fail. 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: Iñigo Martinez Lasala <<A HREF="mailto:%3d%3fISO-8859-1%3fQ%3fI%3dF1igo%3f%3d%20Martinez%20Lasala%20%3cimartinez [at] vectorsf.com%3e">imartinez [at] vectorsf.com</A>> 
Subject: RE: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 08:59:34 +0100 
 

Dear Iñigo, 
 
 
 
Thank you very much. What do you mean by ‘pk’? 
 
I am sorry. 
 
 
 
Thank you very much 
 
 
 
Renato 
 
 
 
 

Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A>

Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK

 

From: Iñigo Martinez Lasala [mailto:imartinez [at] vectorsf.com] 
Sent: 13 April 2010 08:56 
To: Renato Oliveira 
Cc: pgsql-admin [at] postgresql.org; Steve Fisher 
Subject: Re: [ADMIN] 'COPY' Statement 
 
 
 
 
I think it depends of your datamodel and specifically of your table constraints. 
 
For example, if you have a table with a pk generated by a sequence, you will have to deal with it before importing into your New_DB02. But for a plain log table without constrains you can dump it an import into your "just loaded" New_DB02 without any problem. 
 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: pgsql-admin [at] postgresql.org <<A HREF="mailto:%22pgsql-admin [at] postgresql.org%22%20%3cpgsql-admin [at] postgresql.org%3e">pgsql-admin [at] postgresql.org</A>> 
Cc: Steve Fisher <<A HREF="mailto:Steve%20Fisher%20%3csteve.fisher [at] grant.co.uk%3e">steve.fisher [at] grant.co.uk</A>> 
Subject: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 08:42:19 +0100 
 
Dear all, 
 
 
 
I just had a thought, another one. Please the guys who have the powerful knowledge I need your help ;-) 
 
 
 
Let’s suppose 
 
I have Three DB servers ,physical servers – let’s call them: 
 
· Original_DB01 
 
· New_DB02 
 
· Third_DB03 
 
 
 
1 – Let’s suppose I have a PostgreSQL on ‘Original_DB01’ server with a Data Base of 162GB in size. 
 
2 – Let’s suppose I buy a new server ‘New_DB02’ - all singing all dancing cool server, RAID10, 25GB RAM, 64Bit etc. 
 
3 – Let’s suppose I backup the old server with pg_dump to a file “pg_dump_original_DB01” 
 
4 – Let’s also suppose I backup the schema only from ‘Original_DB01’and restore it to ‘Third_DB03’. 
 
5 – Straight after I backup the schema, I stop PostgreSQL on ‘Original_DB01’. 
 
6 – Then I restore the schema to ‘Third_DB03’ and point the application to it. 
 
7 – Let’s suppose the application can create tables and can start using the database on ‘Third_DB03’ and adding new data. 
 
8 – Let’s suppose I restore the FULL pg_dump file “pg_dump_original_DB01” to ‘New_DB02’ 
 
9 – Once the pg_dump has been restored to ‘New_DB02’ I can then point the application to it and data will be added to it straight away. 
 
 
 
Question: 
 
10 – Can I use ‘COPY’ statement to transfer the data from ‘Third_DB03’ to ‘New_DB02’ without ‘WIPING’ or Deleting the existing data? 
 
I want to merge the DATA from ‘Third_DB03’ to ‘New_DB02’ without deleting the Database or the existing data on the existing database. 
 
 
 
Let me explain the Idea behind this craziness. 
 
I am using ‘Third_DB03’ because the amount of data to be transferred from it, will be minimum, and easy to and quick to ‘COPY’ 
 
 
 
This application has two part components (Data and Alarms) 
 
We can get the data back in a very hard way, but without the data being in the database we can’t generate alarms. 
 
 
 
I would very much appreciate all your help on this idea, please. 
 
I would be very glad and grateful for any comments and improvements on this idea, picking the holes etc. 
 
 
 
Thank you very much in advance 
 
 
 
Renato 
 
 
 
 
 
 
 
 
 Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A> Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK 
 
 
 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s). 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A> 
 
 

 

 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 

 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A>
 
</BODY>
</HTML>

--=-tIQ7TCSJy17kCxzf/+FS--

--=-cwTuZAFb56F/84ZhxlcQ
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Then you will have no problem.

When using pg_dump do NOT include the "-c" flag (clean). For example:

pg_dump -U postgres -Fc -d DB_3 -f DB_3.dmp DB3
pg_restore -U postgres -Fc -d DB_2 DB3_dmp 2>error_import.log
1>import.log

Or if you prefer, use plan text (in order to check dump file with an
editor prior restoring):
pg_dump -U postgres -Fp -d DB_3 -f DB_3.dmp DB3
psql -U postgres -d DB_2 -f DB_3.dmp 2>error_import.log 1>import.log

You could alse use the "insert" way, but restore will take much longer.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: I=C3=B1igo Martinez Lasala <imartinez [at] vectorsf.com>
Subject: RE: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 09:13:06 +0100

=EF=BB=BF
I see! Primary Key. Cool.

I think you can work out and change the primary key, that=E2=80=99s is th=
e
reason I am moving the application to third_server so we have very
little data to worry about.

Thank you very much for all your help and comments.

In resume I can =E2=80=98COPY all the data from third_server and use the =
same
COPY statement to migrate the data back to new_server?

Thank you

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk

Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

From: I=C3=B1igo Martinez Lasala [mailto:imartinez [at] vectorsf.com]
Sent: 13 April 2010 09:02
To: Renato Oliveira
Cc: pgsql-admin
Subject: RE: [ADMIN] 'COPY' Statement

Primary Key. :)

A Primary Key is always a constraint, since it cannot be duplicated. For
example, if you have a PK generated by a sequence starting at zero, when
you restore your third database into new server you will have duplicated
values in this column and COPY command will fail.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: I=C3=B1igo Martinez Lasala <imartinez [at] vectorsf.com>
Subject: RE: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:59:34 +0100

=EF=BB=BF Dear I=C3=B1igo,

Thank you very much. What do you mean by =E2=80=98pk=E2=80=99?

I am sorry.

Thank you very much

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK
From: I=C3=B1igo Martinez Lasala [mailto:imartinez [at] vectorsf.com]
Sent:13 April 2010 08:56
To:Renato Oliveira
Cc:pgsql-admin [at] postgresql.org; Steve Fisher
Subject: Re: [ADMIN] 'COPY' Statement

I think it depends of your datamodel and specifically of your table
constraints.

For example, if you have a table with a pk generated by a sequence, you
will have to deal with it before importing into your New_DB02. But for a
plain log table without constrains you can dump it an import into your
"just loaded" New_DB02 without any problem.

-----Original Message-----
From: Renato Oliveira <renato.oliveira [at] grant.co.uk>
To: pgsql-admin [at] postgresql.org <pgsql-admin [at] postgresql.org>
Cc: Steve Fisher <steve.fisher [at] grant.co.uk>
Subject: [ADMIN] 'COPY' Statement
Date: Tue, 13 Apr 2010 08:42:19 +0100

Dear all,

I just had a thought, another one. Please the guys who have the powerful
knowledge I need your help ;-)

Let=E2=80=99s suppose

I have Three DB servers ,physical servers =E2=80=93 let=E2=80=99s call t=
hem:

=C2=B7 Original_DB01

=C2=B7 New_DB02

=C2=B7 Third_DB03

1 =E2=80=93 Let=E2=80=99s suppose I have a PostgreSQL on =E2=80=98Origina=
l_DB01=E2=80=99 server with a
Data Base of 162GB in size.

2 =E2=80=93 Let=E2=80=99s suppose I buy a new server =E2=80=98New_DB02=E2=
=80=99 - all singing all
dancing cool server, RAID10, 25GB RAM, 64Bit etc.

3 =E2=80=93 Let=E2=80=99s suppose I backup the old server with pg_dump to=
a file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D

4 =E2=80=93 Let=E2=80=99s also suppose I backup the schema only from =E2=80=
=98Original_DB01=E2=80=99and
restore it to =E2=80=98Third_DB03=E2=80=99.

5 =E2=80=93 Straight after I backup the schema, I stop PostgreSQL on
=E2=80=98Original_DB01=E2=80=99.

6 =E2=80=93 Then I restore the schema to =E2=80=98Third_DB03=E2=80=99 and=
point the application
to it.

7 =E2=80=93 Let=E2=80=99s suppose the application can create tables and c=
an start using
the database on =E2=80=98Third_DB03=E2=80=99 and adding new data.

8 =E2=80=93 Let=E2=80=99s suppose I restore the FULL pg_dump file
=E2=80=9Cpg_dump_original_DB01=E2=80=9D to =E2=80=98New_DB02=E2=80=99

9 =E2=80=93 Once the pg_dump has been restored to =E2=80=98New_DB02=E2=80=
=99 I can then point
the application to it and data will be added to it straight away.

Question:

10 =E2=80=93 Can I use =E2=80=98COPY=E2=80=99 statement to transfer the d=
ata from =E2=80=98Third_DB03=E2=80=99
to =E2=80=98New_DB02=E2=80=99 without =E2=80=98WIPING=E2=80=99 or Deletin=
g the existing data?

I want to merge the DATA from =E2=80=98Third_DB03=E2=80=99 to =E2=80=98Ne=
w_DB02=E2=80=99 without
deleting the Database or the existing data on the existing database.

Let me explain the Idea behind this craziness.

I am using =E2=80=98Third_DB03=E2=80=99 because the amount of data to be =
transferred
from it, will be minimum, and easy to and quick to =E2=80=98COPY=E2=80=99

This application has two part components (Data and Alarms)

We can get the data back in a very hard way, but without the data being
in the database we can=E2=80=99t generate alarms.

I would very much appreciate all your help on this idea, please.

I would be very glad and grateful for any comments and improvements on
this idea, picking the holes etc.

Thank you very much in advance

Renato

Renato Oliveira
Systems Administrator
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811
Fax: +44 (0)1763 262410
www.grant.co.uk Grant Instruments (Cambridge) Ltd

Company registered in England, registration number 658133

Registered office address:
29 Station Road,
Shepreth,
CAMBS SG8 6GB
UK

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.
VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).
OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

P Please consider the environment before printing this email

CONFIDENTIALITY: The information in this e-mail and any attachments is
confidential. It is intended only for the named recipients(s). If you
are not the named recipient please notify the sender immediately and do
not disclose the contents to another person or take copies.

VIRUSES: The contents of this e-mail or attachment(s) may contain
viruses which could damage your own computer system. Whilst Grant
Instruments (Cambridge) Ltd has taken every reasonable precaution to
minimise this risk, we cannot accept liability for any damage which you
sustain as a result of software viruses. You should therefore carry out
your own virus checks before opening the attachment(s).

OpenXML: For information about the OpenXML file format in use within
Grant Instruments please visit our website

--=-cwTuZAFb56F/84ZhxlcQ
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3">
</HEAD>
<BODY>
Then you will have no problem. 
 
When using pg_dump do NOT include the "-c" flag (clean). For example: 
 
pg_dump -U postgres -Fc -d DB_3 -f DB_3.dmp DB3 
pg_restore -U postgres -Fc -d DB_2 DB3_dmp 2>error_import.log 1>import.log 
 
Or if you prefer, use plan text (in order to check dump file with an editor prior restoring): 
pg_dump -U postgres -Fp -d DB_3 -f DB_3.dmp DB3 
psql -U postgres -d DB_2 -f DB_3.dmp 2>error_import.log 1>import.log 
 
You could alse use the "insert" way, but restore will take much longer. 
 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: Iñigo Martinez Lasala <<A HREF="mailto:%3d%3fISO-8859-1%3fQ%3fI%3dF1igo%3f%3d%20Martinez%20Lasala%20%3cimartinez [at] vectorsf.com%3e">imartinez [at] vectorsf.com</A>> 
Subject: RE: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 09:13:06 +0100 
 

I see! Primary Key. Cool. 
 
I think you can work out and change the primary key, that’s is the reason I am moving the application to third_server so we have very little data to worry about. 
 
 
 
Thank you very much for all your help and comments. 
 
 
 
In resume I can ‘COPY all the data from third_server and use the same COPY statement to migrate the data back to new_server? 
 
 
 
Thank you 
 
 
 
Renato 
 
 
 
 

Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk

Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A>

Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK

 

From: Iñigo Martinez Lasala [mailto:imartinez [at] vectorsf.com] 
Sent: 13 April 2010 09:02 
To: Renato Oliveira 
Cc: pgsql-admin 
Subject: RE: [ADMIN] 'COPY' Statement 
 
 
 
 
Primary Key. :) 
 
A Primary Key is always a constraint, since it cannot be duplicated. For example, if you have a PK generated by a sequence starting at zero, when you restore your third database into new server you will have duplicated values in this column and COPY command will fail. 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: Iñigo Martinez Lasala <<A HREF="mailto:%3d%3fISO-8859-1%3fQ%3fI%3dF1igo%3f%3d%20Martinez%20Lasala%20%3cimartinez [at] vectorsf.com%3e">imartinez [at] vectorsf.com</A>> 
Subject: RE: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 08:59:34 +0100 
 
 Dear Iñigo, 
 
 
 
Thank you very much. What do you mean by ‘pk’? 
 
I am sorry. 
 
 
 
Thank you very much 
 
 
 
Renato 
 
 
 
 
 Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A> Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK 
 From: Iñigo Martinez Lasala [mailto:imartinez [at] vectorsf.com] 
Sent:13 April 2010 08:56 
To:Renato Oliveira 
Cc:pgsql-admin [at] postgresql.org; Steve Fisher 
Subject: Re: [ADMIN] 'COPY' Statement 
 
 
 
 
I think it depends of your datamodel and specifically of your table constraints. 
 
For example, if you have a table with a pk generated by a sequence, you will have to deal with it before importing into your New_DB02. But for a plain log table without constrains you can dump it an import into your "just loaded" New_DB02 without any problem. 
 
 
-----Original Message----- 
From: Renato Oliveira <<A HREF="mailto:Renato%20Oliveira%20%3crenato.oliveira [at] grant.co.uk%3e">renato.oliveira [at] grant.co.uk</A>> 
To: pgsql-admin [at] postgresql.org <<A HREF="mailto:%22pgsql-admin [at] postgresql.org%22%20%3cpgsql-admin [at] postgresql.org%3e">pgsql-admin [at] postgresql.org</A>> 
Cc: Steve Fisher <<A HREF="mailto:Steve%20Fisher%20%3csteve.fisher [at] grant.co.uk%3e">steve.fisher [at] grant.co.uk</A>> 
Subject: [ADMIN] 'COPY' Statement 
Date: Tue, 13 Apr 2010 08:42:19 +0100 
 
Dear all, 
 
 
 
I just had a thought, another one. Please the guys who have the powerful knowledge I need your help ;-) 
 
 
 
Let’s suppose 
 
I have Three DB servers ,physical servers – let’s call them: 
 
· Original_DB01 
 
· New_DB02 
 
· Third_DB03 
 
 
 
1 – Let’s suppose I have a PostgreSQL on ‘Original_DB01’ server with a Data Base of 162GB in size. 
 
2 – Let’s suppose I buy a new server ‘New_DB02’ - all singing all dancing cool server, RAID10, 25GB RAM, 64Bit etc. 
 
3 – Let’s suppose I backup the old server with pg_dump to a file “pg_dump_original_DB01” 
 
4 – Let’s also suppose I backup the schema only from ‘Original_DB01’and restore it to ‘Third_DB03’. 
 
5 – Straight after I backup the schema, I stop PostgreSQL on ‘Original_DB01’. 
 
6 – Then I restore the schema to ‘Third_DB03’ and point the application to it. 
 
7 – Let’s suppose the application can create tables and can start using the database on ‘Third_DB03’ and adding new data. 
 
8 – Let’s suppose I restore the FULL pg_dump file “pg_dump_original_DB01” to ‘New_DB02’ 
 
9 – Once the pg_dump has been restored to ‘New_DB02’ I can then point the application to it and data will be added to it straight away. 
 
 
 
Question: 
 
10 – Can I use ‘COPY’ statement to transfer the data from ‘Third_DB03’ to ‘New_DB02’ without ‘WIPING’ or Deleting the existing data? 
 
I want to merge the DATA from ‘Third_DB03’ to ‘New_DB02’ without deleting the Database or the existing data on the existing database. 
 
 
 
Let me explain the Idea behind this craziness. 
 
I am using ‘Third_DB03’ because the amount of data to be transferred from it, will be minimum, and easy to and quick to ‘COPY’ 
 
 
 
This application has two part components (Data and Alarms) 
 
We can get the data back in a very hard way, but without the data being in the database we can’t generate alarms. 
 
 
 
I would very much appreciate all your help on this idea, please. 
 
I would be very glad and grateful for any comments and improvements on this idea, picking the holes etc. 
 
 
 
Thank you very much in advance 
 
 
 
Renato 
 
 
 
 
 
 
 
 
 Renato Oliveira 
Systems Administrator 
e-mail: renato.oliveira [at] grant.co.uk Tel: +44 (0)1763 260811 
Fax: +44 (0)1763 262410 
<A HREF="http://www.grant.co.uk/">www.grant.co.uk</A> Grant Instruments (Cambridge) Ltd 
 
Company registered in England, registration number 658133 
 
Registered office address: 
29 Station Road, 
Shepreth, 
CAMBS SG8 6GB 
UK 
 
 
 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s). 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A> 
 
 
 
 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s). 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A> 
 
 

 

 
 
P Please consider the environment before printing this email 
 
 
CONFIDENTIALITY: The information in this e-mail and any attachments is confidential. It is intended only for the named recipients(s). If you are not the named recipient please notify the sender immediately and do not disclose the contents to another person or take copies. 

 
VIRUSES: The contents of this e-mail or attachment(s) may contain viruses which could damage your own computer system. Whilst Grant Instruments (Cambridge) Ltd has taken every reasonable precaution to minimise this risk, we cannot accept liability for any damage which you sustain as a result of software viruses. You should therefore carry out your own virus checks before opening the attachment(s).

 
OpenXML: For information about the OpenXML file format in use within Grant Instruments please visit our <A HREF="http://www.grant.co.uk/Support/openxml.html">website</A>
 
</BODY>
</HTML>

--=-cwTuZAFb56F/84ZhxlcQ--

'COPY' Statement

Re: 'COPY' Statement

Re: 'COPY' Statement

Re: 'COPY' Statement