Re: pg_restore: [archiver] entry ID -825110830 out of range -- perhaps a corrupt TOC
От | Dennis C |
---|---|
Тема | Re: pg_restore: [archiver] entry ID -825110830 out of range -- perhaps a corrupt TOC |
Дата | |
Msg-id | d8c381b40901201541o40ab76abydd41d2cd98db69e0@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_restore: [archiver] entry ID -825110830 out of range -- perhaps a corrupt TOC ("Scott Marlowe" <scott.marlowe@gmail.com>) |
Ответы |
Re: pg_restore: [archiver] entry ID -825110830 out of range
-- perhaps a corrupt TOC
|
Список | pgsql-general |
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@gmail.com> wrote:
On Tue, Jan 20, 2009 at 11:15 AM, Dennis C <dcswest@gmail.com> wrote:It's kind of important, but... PostgreSQL's dump and restore commands
> 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]
are designed to work from the same versions or going a new version
from an older version. Going backwards is not supported.8.2 or 8.3. Unless you were using a version supplied by a distro,
> But I installed it about a year ago, so whichever was the release then.
> Am trying to restore to the following:
which could go further back.Now's the time to upgrade. 7.4 is the oldest supported version, which
> 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
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?The normal way to run it is to use the -f switch for the file
> cat * | pg_restore -d [databasename]
pg_restore -d dbname -f filename
Not sure there's anything wrong with your way, but I've never used
pg_restore like that.
В списке pgsql-general по дате отправления: