Thread: Dump from cygwin directly to windows

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
rowsof 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

"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
androws 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

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


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
androws 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

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

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

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