Dump from cygwin directly to windows

Started by Mike G.about 21 years ago5 messages
#1Mike G.
mike@thegodshalls.com

Hello,

In testing RC1 today I attempted to use pg_dump -h cygwin_box mydb | psql -h RC1_box mydb

It started off ok but at somepoint while transferring data over in a table it went astray. I started getting rows and rows of syntax errors most of them saying "invalid command \N".

All of the functions, views, and table definitions transferred successfully but none of the data in the tables did.

I swear I did this in an earlier beta version and it worked.

I don't see any option in pg_dump to specify options for the Copy commands issued.

Using the pg_dump as insert statements option seems to be working fine.

Not sure if this would be considered a bug or new feature.

Mike

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mike G. (#1)
Re: Dump from cygwin directly to windows

"Mike G." <mike@thegodshalls.com> writes:

In testing RC1 today I attempted to use pg_dump -h cygwin_box mydb | psql -h RC1_box mydb

It started off ok but at somepoint while transferring data over in a table it went astray. I started getting rows and rows of syntax errors most of them saying "invalid command \N".

This report is really of entirely zero use :-(.

Show us exactly what went wrong, please --- in particular what happened
*before* you started getting all the complaints about \N.

regards, tom lane

#3Mike G
mike@thegodshalls.com
In reply to: Tom Lane (#2)
1 attachment(s)
Re: Dump from cygwin directly to windows

It looks like it started off as a permissions problem. I added the
users to the database before trying again and this time it worked fine.

I have attached the log from the original attempt if you wish to have a
look.

Mike

Show quoted text

On Fri, 2004-12-17 at 22:35, Tom Lane wrote:

"Mike G." <mike@thegodshalls.com> writes:

In testing RC1 today I attempted to use pg_dump -h cygwin_box mydb | psql -h RC1_box mydb

It started off ok but at somepoint while transferring data over in a table it went astray. I started getting rows and rows of syntax errors most of them saying "invalid command \N".

This report is really of entirely zero use :-(.

Show us exactly what went wrong, please --- in particular what happened
*before* you started getting all the complaints about \N.

regards, tom lane

Attachments:

postgresql-2004-12-17_163349.log.bz2application/x-bzip; name=postgresql-2004-12-17_163349.log.bz2Download
#4Tom Lane
tgl@sss.pgh.pa.us
In reply to: Mike G (#3)
Re: Dump from cygwin directly to windows

Mike G <mike@thegodshalls.com> writes:

It looks like it started off as a permissions problem. I added the
users to the database before trying again and this time it worked fine.
I have attached the log from the original attempt if you wish to have a
look.

As best I can tell, you ran the restore script as a non-superuser, which
probably wasn't a good thing to do. 8.0 pg_dump generates scripts that
should cope with this situation a bit more reasonably, but it would
still end up as a do-over in most cases because none of the object
ownerships would come out right.

regards, tom lane

#5Mike G
mike@thegodshalls.com
In reply to: Tom Lane (#4)
Re: Dump from cygwin directly to windows

Ok,

I didn't think you could do a restore as a non-superuser. I had
executed the command on the remote(cygwin) machine in this case. I
didn't specify a user to have it run as on the windows side (thought it
would default to postgres).

On the cygwin side I did execute it under a non-superuser domain
account.

When I first saw all the \N errors I thought it was a unix to windows
end of line character conversion error.

Thanks for your help.

Mike

Show quoted text

On Sat, 2004-12-18 at 11:00, Tom Lane wrote:

Mike G <mike@thegodshalls.com> writes:

It looks like it started off as a permissions problem. I added the
users to the database before trying again and this time it worked fine.
I have attached the log from the original attempt if you wish to have a
look.

As best I can tell, you ran the restore script as a non-superuser, which
probably wasn't a good thing to do. 8.0 pg_dump generates scripts that
should cope with this situation a bit more reasonably, but it would
still end up as a do-over in most cases because none of the object
ownerships would come out right.

regards, tom lane