Re: pg_restore: [archiver] entry ID -825110830 out of range -- perhaps a corrupt TOC

[Dennis C <dcswest@xxxxxxxxx>]

OK that was it!  Wow, thank you so very much!  Nice to know it was just plpython tracking such an obsolete version of postgresql much to my dismay now (especially even going backwards, which didn't even occur to me), as opposed to postgresql itself being less reliable than I've come to expect over the years!  Thanks for all your great work with that too in the first place!

On Tue, Jan 20, 2009 at 10:40 AM, Scott Marlowe <scott.marlowe@xxxxxxxxx> wrote:

On Tue, Jan 20, 2009 at 11:15 AM, Dennis C <dcswest@xxxxxxxxx> wrote:
> Greetings;
> And thanks for your reply!  I tried the following:
> less xaa | grep "^;"
> "xaa" may be a binary file.  See it anyway? y
> Binary file (standard input) matches
>
> And so am not sure which version I did the following from:
> pg_dump -c -F c -Z 9 [databasename]

It's kind of important, but... PostgreSQL's dump and restore commands
are designed to work from the same versions or going a new version
from an older version.  Going backwards is not supported.

> But I installed it about a year ago, so whichever was the release then.
> Am trying to restore to the following:

8.2 or 8.3.  Unless you were using a version supplied by a distro,
which could go further back.

> postgresql-client-7.4.21 PostgreSQL database (client)
> postgresql-plpython-7.4.21_1 A module for using Python to write SQL
> functions
> postgresql-server-7.4.21 The most advanced open-source database available
> anywhere

Now's the time to upgrade.  7.4 is the oldest supported version, which
means it's next for the chopping block.  It's also A LOT slower than
8.3.  Can you get and install a newer version of pgsql, preferably 8.3
and try restoring there?

> cat * | pg_restore -d [databasename]

The normal way to run it is to use the -f switch for the file

pg_restore -d dbname -f filename

Not sure there's anything wrong with your way, but I've never used
pg_restore like that.