"Reuven M. Lerner" <reuven@lerner.co.il> writes:
> Using the Windows process monitor, we saw that pg_restore was using
> about 50 percent of the CPU, doing an enormous (about 60 billion, by
> this point) reads from the disk, but zero writes. The dumpfile does
> contain a number of large (binary) objects, as well as a number of
> regular tables with integer and textual content. The restore was run
> with the -a (data only) flag, on an empty database schema.
That's pretty curious. Can you take the dump file to a non-Windows
machine, or at least one with a different build of pg_restore, and
see what happens there? I'm wondering about possible corrupted
executable, buggy zlib, etc.
> * Is this a known problem on PostgreSQL 8.3, Windows, or the
> combination?
No, not that I've heard of. The most likely theory seems to be that the
dump file is corrupt somehow.
> * Is there any obvious way to diagnose or work around this problem?
Well, it'd be interesting to trace through it with a debugger. Ideally
you shouldn't get an infinite loop (as this seems to be) even with
corrupt input. Is the data sufficiently non-proprietary that you'd be
willing to show the dump file to someone else?
> * I don't believe that there's a way to tell either pg_dump or
> pg_restore to ignore objects with particular OIDs. Am I right?
Try using pg_restore -l, edit the list file, pg_restore -L. That would
let you get the remaining data out, and would also give evidence of
whether there is corruption in the structure of the dump file or just
in the data of the one BLOB.
regards, tom lane
