Re: [GENERAL] Hints about how to debug pg_dump problem?

[Peter Eisentraut]

Philip Warner writes:

> >The read eventually dies with a parse error.  I'm sure there must be
> >something wrong in my source database that I'm getting this, but I don't
> >even know where to begin tracking down the problem.  I've dumped and re-read
> >this database before, but I've added the data that is causing the problem
> >since then.  Obviously, that's what the problem is; I just can't see how the
> >file is getting read.  Any hints as to where to start would be much
> >appreciated.
> 
> The simplest thing to do would be to copy the dump file and edit it; break
> it into bits that you can run independantly, and see where the error occurs.
> 
> P.S. I assume you are using the pg_dump that came with 7.0.2 or earlier.

If it's 7.0.2 you can run psql with -f (instead of <) and with `-V
ON_ERROR_STOP=on' to get error messages with line numbers and immediate
exit if an error occurs.

-- 
Peter Eisentraut  Sernanders väg 10:115
[EMAIL PROTECTED]   75262 Uppsala
http://yi.org/peter-e/Sweden

[GENERAL] Hints about how to debug pg_dump problem?

[Andrew Sullivan]

Hi,

I'm trying to move a database from a development machine onto a production
machine.  I seem to get good output from my pg_dump command, but when I read
the resulting files, I can't get them to import everything.  (FWIW, I'm
moving from a Debian potato/woody combo onto a fresh Debian potato install
with just PostgreSQL updated to the 7.0.2 deb package.)

What I don't understand is the order in which a dump file is processed.  I
thought it should be processed pretty much in the order it appears, right? 
After all, if you do

$ psql -e my_database < my_dumpfile

you should just get a straight-ahead reading of the dumpfile, no?  Watching
the output, however, things are not getting created even though there are no
complaints from psql (about that data).

For instance, if I have data from table1 which appears in the dump file
before data from table2, and I'm getting a parse error on table2, shouldn't
the data from table1 show up (assuming that nothing in it depends on the
data from table2 being there) after the error?

The read eventually dies with a parse error.  I'm sure there must be
something wrong in my source database that I'm getting this, but I don't
even know where to begin tracking down the problem.  I've dumped and re-read
this database before, but I've added the data that is causing the problem
since then.  Obviously, that's what the problem is; I just can't see how the
file is getting read.  Any hints as to where to start would be much
appreciated.

A

-- 
Andrew Sullivan  Computer Services
<[EMAIL PROTECTED]>Burlington Public Library
+1 905 639 3611 x158   2331 New Street
   Burlington, Ontario, Canada L7R 1J4