"G. Anthony Reina" <reina@nsi.edu> writes:
> I think I may have found the error but I can't be sure. I compressed the
> pg_dump'd backup file and then samba'd it to a Windows 95 machine in order to
> burn it to a CD-ROM. I wonder if Windows added extra line feeds here and
> there (although I don't see them when I do a head or tail on the
> file).
If the file was compressed when you transferred it, then any newline
breakage would have messed it up pretty thoroughly... so I doubt that
theory.
Hannu's thought is a good one: corrupted data within a particular COPY
command would probably have caused the entire COPY to fail, but psql
would have recovered at the \. and picked up with the rest of the
restore script, which seems to match the symptoms. I think he's blamed
a long-gone bug, but there could be another one with similar effects.
However, if that happened you should certainly have seen a complaint
from psql (and also in the postmaster log) while running the restore.
Did you look through the output of the restore script carefully?
> All of the tables seemed to be the ones marked ***_proc (e.g.
> center_out_proc, ellipse_proc, etc.). These all seemed to be at the end of
> the pg_dump.
Hmm. What kind of data was in them?
> Yes. They get created just after the copy commands. Of course, it would be
> nice if they were created first and then the data was copied in.
There's a reason for that: it's a lot faster to build the index after
doing the bulk load, rather than incrementally as the data is loaded.
> Again, the text file is over 2 Gig so I can't seem to find an editor that is
> big enough to hold it all in memory (I only have a half a gig of RAM). So it
> really is just guesswork. Anything you can think of to strip the data from
> this big of a file?
Not short of writing a little perl script that looks for COPY ... and \.
But at this point it seems likely that the problem is in the data
itself, so stripping it out would lose the evidence anyway. Grumble.
regards, tom lane