Hi. Tom. You wrote:
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.
I'll try to get a copy of the problematic data file to my Unix box in
the coming days, and will report back on what happens.
No, not that I've heard of. The most likely theory seems to be that the
dump file is corrupt somehow.
This raises a question that came up during our discussion of this
problem: Is there a way to verify that a dumpfile was not corrupt?
That is, without having to run pg_restore on the entire file, only to
discover that the end is missing data. I haven't encountered
data-recovery problems of this sort before, but it does surprise me that
PostgreSQL doesn't check the integrity of the file before trying to read
and then apply it.
* 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'm guessing that if we have dummy data in there, then we can share it.
I'll get back to you about this in the coming day or two. Thanks for
the offer!
Reuven
--
Reuven M. Lerner -- Web development, consulting, and training
Mobile: +972-54-496-8405 * US phone: 847-230-9795
Skype/AIM: reuvenlerner
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
