From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Reuven M(dot) Lerner" <reuven(at)lerner(dot)co(dot)il> |
Cc: | Alban Hertroys <dalroi(at)solfertje(dot)student(dot)utwente(dot)nl>, pgsql-general(at)postgresql(dot)org, eli-d(at)nova(dot)co(dot)il |
Subject: | Re: Hanging with pg_restore and large objects |
Date: | 2010-12-07 21:40:05 |
Message-ID: | 28940.1291758005@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
"Reuven M. Lerner" <reuven(at)lerner(dot)co(dot)il> writes:
> Hi, everyone. Alban wrote:
>> Which version of pg_dump did you use? The one that came with the 9.0 install or the one from the old 8.3 one? It should have been the first of these two.
> The dump was done by someone using the old, existing system, which runs
> under 8.3.
Hmmm ... I wonder whether this is related to the known problem that
8.3's pg_dump doesn't correctly detect file seekability under Windows:
http://archives.postgresql.org/pgsql-hackers/2010-06/msg01227.php
That means the dump file will not contain any data offset pointers.
Up to now that was only known to cause issues for parallel pg_restore,
but maybe you found another case. But that's just a hypothesis, and a
quick test here doesn't seem to support it: I can still do pg_restore -a
from a blob-containing dump that I forced to not have data offsets.
OTOH I'm not using Windows.
Does it work any better if you use 9.0's pg_dump to dump from the 8.3
server?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | James B. Byrne | 2010-12-07 21:54:14 | PG84 and SSL on CentOS-5.5 was PG84 and SELinux |
Previous Message | Reuven M. Lerner | 2010-12-07 20:56:17 | Re: Hanging with pg_restore and large objects |