Re: Hanging with pg_restore and large objects

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

In response to

Browse pgsql-general by date

  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