|From:||Ørjan Vøllestad <orjan(dot)vollestad(at)itet(dot)no>|
|Subject:||dump & restore problem|
|Views:||Raw Message | Whole Thread | Download mbox|
Hello Kees, Ørjan Vøllestad from Norway here.
I'm working with a pgsql base, and have some trouble during backup &
My problem look very familiar to a problem you had one time(Wed, 19 Aug
1998), so I wonder if you could
help me with this.
I assume you made the upgrade, and another one later.
You posted this to pgsql-admin mailling list once:
My apologies for sending this question to the list twice. Due to a glitch in
our procmail configuration, I lost all mail that I should have received
overnight, including any answers to this question. I have a problem with
upgrading postgresql 6.1 to 6.3.2. Compilation and installation of the
database system is no problem, the trouble start when I try to move the
contents of the old database to the new one. This is the procedure I
followed. 0. Platform is: SunOS epidemix 5.5 Generic_103093-06 sun4m sparc
SUNW,SPARCstation-4 1. compile version 6.3.2 2. run 6.3.2 version of
pg_dumpall to dump the contents of the old database. The old poster is still
running This will lead to a number of warnings/errors about the pg_shadow
table, i.e. that it does not exist. From the documentation , I understand
that this is correct since 6.1 doesn't have this table. When I check the
captured output of pg_dumpall, none of my users has been saved to the
output. Needless to say, I also dumped the database with the old version of
pg_dumpall. During the dump process, no errors or warnings occur. 3. kill
the postmaster. Renamed postgres directory to postgres.old, created new
postgres directory. Went back to source and did gnu-make install, followed
by initdb. No problems occured. 4. When I try to reload my old data from the
dump that has been made with the 6.3.2 version of pg_dumpall, no users are
created and the restore process stops. If I create the users manually and
then remove the first few lines from db.out that are responsible for
deleting the body of pg_shadow, the restore process stops with an error that
mentions a buffer overflow When I try to reload my old data from the dump
that has been made with the 6.1 version of pg_dumpall, my users are created,
but I get an error that the users are not listed in pg_shadow and the
restore process stops. >From the documentation, I understood that pg_user
now is a view of pg_shadow, how is it possible then that when I update
pg_user, the changes are not made to pg_shadow? Anyhow, I've been trying for
a day and a half to restore my database and nothing works. Since it is a
more-or-less production database, I restored the 6.1 copy so that we could
continue our work. What is wrong? And more importantly, how do I fix it?!
Thanks in advance for your reactions! -Kees
I am running PostgreSQL 6.3.2 on a Red Hat 5.2 system (a pretty old server).
Upgrading the Hardware, and all the Software. Upgrading PostgreSQL to
During the dump, I use 6.3.2 version of pg_dump(all) and get no errors, but
when I restore the db.out file on the new server, with Pgsql 7.0.2 get
errors with "User Authentication". I looked in the old base, and the user
"nobody" owned it all, but I dumped it with user "postgres". In the restore
I used the user "postgres", but since the user "nobody" wasn't in pg_shadow,
I had to create the user "nobody". Now I after I had restored the base, I
looked inside the base manually I saw that all of the "INDEX" - types were
missing, the restore had just restored these types: "TABLE" and "SEQUENCE".
I tried more times, with just negative results. :-(
If you don't want to help me, it's ok, but I really need to make this
Thanks for your help anyway!
Ørjan Vøllestad, iTet AS
Alkeveien 4, 9015 Tromsø
Postboks 2033, 9265 Tromsø
Tel: +47 77 67 91 00, Fax: +47 77 67 91 01
Dir: +47 77 64 78 22, GSM: +47 95 92 46 77
"The LinuX-Files - The source is out there"
|Next Message||Trurl McByte||2000-12-08 07:57:43||Re: Re: [ADMIN] pg_dump backup problems with password authentication|
|Previous Message||G. Anthony Reina||2000-12-08 02:24:20||RAID vs. Single Big SCSI Disk|