473,394 Members | 1,350 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,394 software developers and data experts.

Dump 7.1.3->7.4.2


I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.

It doesn't works because of difference in COPY format (unless I use -d
which is VERY slow on a 16G database).

What are the difference between the 7.1.3 and 7.4.2 formats (seems to be
related at least to newlines) ? Is it possible to modify the dump with a sed
script to make it usable by 7.4.2 ?

Thanks

cyril
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org

Nov 23 '05 #1
7 2032
"Cyril VELTER" <cy**********@metadys.com> writes:
I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.

It doesn't works because of difference in COPY format (unless I use -d
which is VERY slow on a 16G database).


Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
database. pg_dump is written to talk to multiple versions of the
server, and it's generally recommended to use the same version of
pg_dump as the server you're restoring into.

-Doug

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 23 '05 #2

From: "Doug McNaught" <do**@mcnaught.org>

"Cyril VELTER" <cy**********@metadys.com> writes:
I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.

It doesn't works because of difference in COPY format (unless I use -d which is VERY slow on a 16G database).


Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
database. pg_dump is written to talk to multiple versions of the
server, and it's generally recommended to use the same version of
pg_dump as the server you're restoring into.


That's what I already do, but the problem is in COPY TO format (which is
handled by the backend ? right ?)

cyril
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #3
On Mon, May 31, 2004 at 07:57:01AM +0200, Cyril VELTER wrote:

From: "Doug McNaught" <do**@mcnaught.org>
"Cyril VELTER" <cy**********@metadys.com> writes:
I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.
It doesn't works because of difference in COPY format (unless I
use -d which is VERY slow on a 16G database).


Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
database. pg_dump is written to talk to multiple versions of the
server, and it's generally recommended to use the same version of
pg_dump as the server you're restoring into.


That's what I already do, but the problem is in COPY TO format
(which is handled by the backend ? right ?)


What backend? 7.4-pg_dump will generate 7.4-backend's compatible
input, and the 7.1-backend does not interact at all --- save with
7.4-pg_dump, which will make itself understood easily ...

Lots of people (including me) use this procedure to upgrade rather
smoothly. What's your problem exactly?

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"In a specialized industrial society, it would be a disaster
to have kids running around loose." (Paul Graham)
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Nov 23 '05 #4

From: "Alvaro Herrera" <al******@dcc.uchile.cl>
On Mon, May 31, 2004 at 07:57:01AM +0200, Cyril VELTER wrote:
From: "Doug McNaught" <do**@mcnaught.org>
"Cyril VELTER" <cy**********@metadys.com> writes:

> I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.
> It doesn't works because of difference in COPY format (unless I
> use -d which is VERY slow on a 16G database).

Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
database. pg_dump is written to talk to multiple versions of the
server, and it's generally recommended to use the same version of
pg_dump as the server you're restoring into.


That's what I already do, but the problem is in COPY TO format
(which is handled by the backend ? right ?)


What backend? 7.4-pg_dump will generate 7.4-backend's compatible
input, and the 7.1-backend does not interact at all --- save with
7.4-pg_dump, which will make itself understood easily ...

Lots of people (including me) use this procedure to upgrade rather
smoothly. What's your problem exactly?


Thanks for your response,

Perhaps I'm mistaken, but it seems that pg_dump (the 7.4 one) will send
a COPY to STDOUT command to the 7.1 backend and blindly copy the output to
the dump file.

Here's the kind of errors I get :

ERROR: literal carriage return found in data
HINT: Use "\r" to represent carriage return.
CONTEXT: COPY c244, line 221: "662188 1002 1002 2002-08-05
12:15:12.20+00 2002-08-05 12:15:12.20+00 274 0000
01000100202010000000000..."

By looking more closely in the dump file, there is a CR (embedded in a
text field) which is not encoded and confuse the restore

cyril
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

Nov 23 '05 #5
Quoting Cyril VELTER <cy**********@metadys.com>:

From: "Alvaro Herrera" <al******@dcc.uchile.cl>
On Mon, May 31, 2004 at 07:57:01AM +0200, Cyril VELTER wrote:
From: "Doug McNaught" <do**@mcnaught.org>
> "Cyril VELTER" <cy**********@metadys.com> writes:
>
> > I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.
> > It doesn't works because of difference in COPY format (unless I
> > use -d which is VERY slow on a 16G database).
>
> Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
> database. pg_dump is written to talk to multiple versions of the
> server, and it's generally recommended to use the same version of
> pg_dump as the server you're restoring into.

That's what I already do, but the problem is in COPY TO format
(which is handled by the backend ? right ?)


What backend? 7.4-pg_dump will generate 7.4-backend's compatible
input, and the 7.1-backend does not interact at all --- save with
7.4-pg_dump, which will make itself understood easily ...

Lots of people (including me) use this procedure to upgrade rather
smoothly. What's your problem exactly?


Thanks for your response,

Perhaps I'm mistaken, but it seems that pg_dump (the 7.4 one) will send
a COPY to STDOUT command to the 7.1 backend and blindly copy the output to
the dump file.

Here's the kind of errors I get :

ERROR: literal carriage return found in data
HINT: Use "\r" to represent carriage return.
CONTEXT: COPY c244, line 221: "662188 1002 1002 2002-08-05
12:15:12.20+00 2002-08-05 12:15:12.20+00 274 0000
01000100202010000000000..."

By looking more closely in the dump file, there is a CR (embedded in a
text field) which is not encoded and confuse the restore

cyril
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly


Cyril,

Maybe I'm misunderstanding you but are you saying you already have the dump
file? If not (of if you can connect to the 7.1.3 server with the 7.4.x dump
program), you can, over tcp/ip, dump the data from 7.1.3 to a file and then
reload that file into your 7.4.x cluster. I've upgraded 7.1.3 to 7.4 and 7.4.1
this way after I found out that the 7.4 pg_dump had problem reading the 7.1.3
file. This is way folks are saying its best to use the dump utils from your
destination cluster (7.4.2 in your case) to move your data.

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #6
De : mailto:ne******@vcsn.com
Emission : 02/06/2004 15:59:31
Quoting Cyril VELTER <cy**********@metadys.com>:
From: "Alvaro Herrera" <al******@dcc.uchile.cl>
On Mon, May 31, 2004 at 07:57:01AM +0200, Cyril VELTER wrote:
> From: "Doug McNaught" <do**@mcnaught.org>
> > "Cyril VELTER" <cy**********@metadys.com> writes:
> >
> > > I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one.
> > > It doesn't works because of difference in COPY format (unless I
> > > use -d which is VERY slow on a 16G database).
> >
> > Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
> > database. pg_dump is written to talk to multiple versions of the
> > server, and it's generally recommended to use the same version of
> > pg_dump as the server you're restoring into.
>
> That's what I already do, but the problem is in COPY TO format
> (which is handled by the backend ? right ?)

What backend? 7.4-pg_dump will generate 7.4-backend's compatible
input, and the 7.1-backend does not interact at all --- save with
7.4-pg_dump, which will make itself understood easily ...

Lots of people (including me) use this procedure to upgrade rather
smoothly. What's your problem exactly?
Thanks for your response,

Perhaps I'm mistaken, but it seems that pg_dump (the 7.4 one) will send
a COPY to STDOUT command to the 7.1 backend and blindly copy the output to
the dump file.

Here's the kind of errors I get :

ERROR: literal carriage return found in data
HINT: Use "\r" to represent carriage return.
CONTEXT: COPY c244, line 221: "662188 1002 1002 2002-08-05
12:15:12.20+00 2002-08-05 12:15:12.20+00 274 0000
01000100202010000000000..."

By looking more closely in the dump file, there is a CR (embedded in a
text field) which is not encoded and confuse the restore


Maybe I'm misunderstanding you but are you saying you already have the dump
file? If not (of if you can connect to the 7.1.3 server with the 7.4.x dump
program), you can, over tcp/ip, dump the data from 7.1.3 to a file and then
reload that file into your 7.4.x cluster. I've upgraded 7.1.3 to 7.4 and

7.4.1 this way after I found out that the 7.4 pg_dump had problem reading the 7.1.3
file. This is way folks are saying its best to use the dump utils from your
destination cluster (7.4.2 in your case) to move your data.


I've two postgres instances on two different machines (one is 7.1.3 under
cygwin the other 7.4.2 under linux). I use the 7.4 pg_dump binary under linux
to dump the 7.1 database either to a file to inspect it or piped to the 7.4
psql connected to the 7.4 database.

I hope this is more clear.

I've worked out a solution which I have only tested on some tables. I use sed
to replace embeded cr by the escaped form (\r). Will test this out with the
complete database.
Perhaps it's because of cygwin ?

Thanks,

Cyril

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Nov 23 '05 #7
Quoting Cyril VELTER <cy**********@metadys.com>:
De : mailto:ne******@vcsn.com
Emission : 02/06/2004 15:59:31
Quoting Cyril VELTER <cy**********@metadys.com>:
From: "Alvaro Herrera" <al******@dcc.uchile.cl>
> On Mon, May 31, 2004 at 07:57:01AM +0200, Cyril VELTER wrote:
> > From: "Doug McNaught" <do**@mcnaught.org>
> > > "Cyril VELTER" <cy**********@metadys.com> writes:
> > >
> > > > I'm trying to dump a database from a 7.1.3 server to a 7.4.2 one. > > > > It doesn't works because of difference in COPY format (unless I
> > > > use -d which is VERY slow on a 16G database).
> > >
> > > Try using the 7.4.2 version of pg_dump to dump out the 7.1.3
> > > database. pg_dump is written to talk to multiple versions of the
> > > server, and it's generally recommended to use the same version of
> > > pg_dump as the server you're restoring into.
> >
> > That's what I already do, but the problem is in COPY TO format
> > (which is handled by the backend ? right ?)
>
> What backend? 7.4-pg_dump will generate 7.4-backend's compatible
> input, and the 7.1-backend does not interact at all --- save with
> 7.4-pg_dump, which will make itself understood easily ...
>
> Lots of people (including me) use this procedure to upgrade rather
> smoothly. What's your problem exactly?

Thanks for your response,

Perhaps I'm mistaken, but it seems that pg_dump (the 7.4 one) will send a COPY to STDOUT command to the 7.1 backend and blindly copy the output to the dump file.

Here's the kind of errors I get :

ERROR: literal carriage return found in data
HINT: Use "\r" to represent carriage return.
CONTEXT: COPY c244, line 221: "662188 1002 1002 2002-08-05
12:15:12.20+00 2002-08-05 12:15:12.20+00 274 0000
01000100202010000000000..."

By looking more closely in the dump file, there is a CR (embedded in a text field) which is not encoded and confuse the restore


Maybe I'm misunderstanding you but are you saying you already have the

dump
file? If not (of if you can connect to the 7.1.3 server with the 7.4.x

dump
program), you can, over tcp/ip, dump the data from 7.1.3 to a file and

then
reload that file into your 7.4.x cluster. I've upgraded 7.1.3 to 7.4 and

7.4.1
this way after I found out that the 7.4 pg_dump had problem reading the

7.1.3
file. This is way folks are saying its best to use the dump utils from

your
destination cluster (7.4.2 in your case) to move your data.


I've two postgres instances on two different machines (one is 7.1.3 under
cygwin the other 7.4.2 under linux). I use the 7.4 pg_dump binary under linux

to dump the 7.1 database either to a file to inspect it or piped to the 7.4
psql connected to the 7.4 database.

I hope this is more clear.

I've worked out a solution which I have only tested on some tables. I use
sed
to replace embeded cr by the escaped form (\r). Will test this out with the
complete database.
Perhaps it's because of cygwin ?

Thanks,

Cyril


Not so much cygwin but the fact that the newline characters are different maybe?

--
Keith C. Perry, MS E.E.
Director of Networks & Applications
VCSN, Inc.
http://vcsn.com

____________________________________
This email account is being host by:
VCSN, Inc : http://vcsn.com

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Nov 23 '05 #8

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

0
by: Ravi Tallury | last post by:
Hi We are having issues with our application, certain portions of it stop responding while the rest of the application is fine. I am attaching the Java Core dump. If someone can let me know what...
3
by: Chris Stiles | last post by:
Is there a human readable dump format for objects ? As opposed to pickling ? It doesn't necessarily have to be XML - in fact i'd prefer if it wasn't ;) - but ISTR an XML dump library. --...
2
by: Gregory Stone | last post by:
I have a situation where I am doing a pg_dump from my database. I want to make sure that noone is inserting into the tables being dump during the dump. Does the MVCC architecture make it a moot...
7
by: Matt | last post by:
I want to know what is Hex Dump? I tried to search in google but didn't get useful results. I know it is the hexademical representation of something. But I don't know what is something? From C...
9
by: Microsoft News Server | last post by:
Hi, I am currently having a problem with random, intermittent lock ups in my ASP.net application on our production server (99% CPU usage by 3 threads, indefinately). I currently use IIS Debug...
3
by: Andrei Ivanov | last post by:
Hello, I have a dump created with pg_dump ver 7.4.1 from a postgres 7.4 database, with encoding SQL_ASCII. I'm trying to import this dump in a 7.4.1 postgres database with encoding UNICODE, but...
6
by: Együd Csaba | last post by:
Hi All, I'd like to dump out my database using plain text format. Everything is ok, but the bytea filds. Restoring the dump file (using <<psql -f LO_TRY_INSERT_BYTEA.sql tmp7>>) it sends an...
6
by: Soeren Gerlach | last post by:
Hi, some weeks ago I started to develop an application using Postgresql the first time. I'm running 7.4.3 on a Linux box with a plain 2.6.7 kernel, the storage is handled by 5 SATA disks,...
2
by: Oleg | last post by:
Dear All, I have upgraded Postgresql from 7.3 to 7.4. Starting pg brings error: The database is in an older format that cannot be read by version 7.4 of PostgreSQL dpkg-upgrade postgresql...
1
by: dekel | last post by:
I'm trying to find the way to create and debug dumpfile of dotnet application. Any recommendation of articles, tools for creating dump file + debug it are appreciated. The documentation I...
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: emmanuelkatto | last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud. Please let me know. Thanks! Emmanuel
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
0
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.