Обсуждение: pg_dump.... pg_restore...how long does it take?
Hi, I've dumped my database into archive by using following command: .\pg_dump -U tad -ci -F t -f openbravo.tar openbravo. Everything seemed to be all right and the whole process was very fast. Afterwards I've got tar file which size is about 4MB. I've got also the following message after dumping: pg_dump: [tar archiver] actual file length (4104361) does not match expected (4104361) which in fact does not make sense for me. Then I've copied tar archive to another computer to restore the database using following command: pg_restore -d openbravo ..\openbravo.tar The process started about 18hours ago and still runs. I've checked task manager and noticed that pg_restore still uses 50% of CPU. The question is: Have I done everything correctly? Since the tar archive has only 4MB and was generated in few second, I wonder why restoring takes so long? How long it can take? Does anybody have such an experience? Looking forward any support. BR, Rafal -- View this message in context: http://www.nabble.com/pg_dump....-pg_restore...how-long-does-it-take--tf4347124.html#a12385020 Sent from the PostgreSQL - general mailing list archive at Nabble.com.
rafikoko <rako@wapice.com> writes: > I've got also the following message after dumping: > pg_dump: [tar archiver] actual file length (4104361) does not match expected > (4104361) > which in fact does not make sense for me. Hmm, it looks like that code is printing the wrong variable's value. However, the condition it's complaining of shouldn't have happened, so you need to look more closely. I suspect you've got a corrupt tar archive. Does it look sane if you do "tar tvf" on it? regards, tom lane
Hi, Thanks for the answer. I've checked and the archive is corrupted. Every time I dump my database with pg_dump command mentioned in the previous post, I've got the same error. Could you please suggest me other compination of parameters for pg_dump, so that it dumps complete database (inluding functions, triggers, procedures, operators, sequences, tables, views etc. and obviously data)? It doesn't have to be stored in .tar archive. Moreover I'd like to inform that I work in Windows environment. Looking forward the answer. BR, Rafal Tom Lane-2 wrote: > > rafikoko <rako@wapice.com> writes: >> I've got also the following message after dumping: >> pg_dump: [tar archiver] actual file length (4104361) does not match >> expected >> (4104361) >> which in fact does not make sense for me. > > Hmm, it looks like that code is printing the wrong variable's value. > However, the condition it's complaining of shouldn't have happened, > so you need to look more closely. I suspect you've got a corrupt > tar archive. Does it look sane if you do "tar tvf" on it? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > > -- View this message in context: http://www.nabble.com/pg_dump....-pg_restore...how-long-does-it-take--tf4347124.html#a12402596 Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Hi, Thanks for the answer. I've checked and the archive is corrupted. Every time I dump my database with pg_dump command mentioned in the previous post, I've got the same error. Could you please suggest me other compination of parameters for pg_dump, so that it dumps complete database (inluding functions, triggers, procedures, operators, sequences, tables, views etc. and obviously data)? It doesn't have to be stored in .tar archive. Moreover I'd like to inform that I work in Windows environment. Looking forward the answer. BR, rafikoko Tom Lane-2 wrote: > > rafikoko <rako@wapice.com> writes: >> I've got also the following message after dumping: >> pg_dump: [tar archiver] actual file length (4104361) does not match >> expected >> (4104361) >> which in fact does not make sense for me. > > Hmm, it looks like that code is printing the wrong variable's value. > However, the condition it's complaining of shouldn't have happened, > so you need to look more closely. I suspect you've got a corrupt > tar archive. Does it look sane if you do "tar tvf" on it? > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 2: Don't 'kill -9' the postmaster > > -- View this message in context: http://www.nabble.com/pg_dump....-pg_restore...how-long-does-it-take--tf4347124.html#a12404040 Sent from the PostgreSQL - general mailing list archive at Nabble.com.
Hi, Thanks for the answer. I've checked and the archive is corrupted. Every time I dump my database with pg_dump command mentioned in the previous post, I've got the same error. Could you please suggest me other compination of parameters for pg_dump, so that it dumps complete database (inluding functions, triggers, procedures, operators, sequences, tables, views etc. and obviously data)? It doesn't have to be stored in .tar archive. Moreover I'd like to inform that I work in Windows environment. Looking forward the answer. BR, Rafal Tom Lane-2 wrote: > > > I suspect you've got a corrupt > tar archive. Does it look sane if you do "tar tvf" on it? > > > -- View this message in context: http://www.nabble.com/pg_dump....-pg_restore...how-long-does-it-take--tf4347124.html#a12404132 Sent from the PostgreSQL - general mailing list archive at Nabble.com.
rafikoko <rako@wapice.com> writes: > Could you please suggest me other compination of parameters for pg_dump, so > that it dumps complete database (inluding functions, triggers, procedures, > operators, sequences, tables, views etc. and obviously data)? > It doesn't have to be stored in .tar archive. Moreover I'd like to inform > that I work in Windows environment. If you don't have a very specific reason for using -Ft, don't --- the -Fc and plain-sql-script alternatives are much more commonly used and hence better debugged. -Ft also has some other problems like a need for extra temporary files. regards, tom lane