Re: [BUGS] BUG #2386: pg_restore doesn't restore large objects

[Andreas Pflug]

Dave Page wrote:

pgAdmin just uses pg_dump/pg_restore to handle the heavy lifting.

When I try to restore the backup using PGAdmin III, the log 
window begins to fill up. Near the end, when it should say it's 
restoring the BLOBS an error message appears stating the BLOBS

couldn't be restored.


This is the original output from pg_restore. pgAdmin will also log the
precise parameters used to restore in the first log line, it might help
to see those.

Regards,
Andreas

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match

Re: Permission denied on fsync / Win32 (was [BUGS] right

[Peter Brant]

Apparently we got lucky on all four servers with the latest cycle, so
nothing to report.  Load (both reading and writing) is quite light today
so perhaps the bug is only triggered under a higher load.  It seems the
problem typically doesn't show up on weekends either (when load is also
much lighter for us).

In any case, we're logging the relfilenodes before and after now, so
I'll post again when the problem crops up again next week.

Pete

>>> Tom Lane <[EMAIL PROTECTED]> 04/14/06 2:41 am >>>
OK ... but what's still unclear is whether the failures are occurring
against the old relfilenode (the one just removed by the CLUSTER) or
the
new one just added by CLUSTER.  If you note the relfilenodes assigned
to
these tables just before and just after the next cycle of CLUSTERs, it
should be easy to tell what the complaints refer to.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly