Thread: pg_dump.... pg_restore...how long does it take?

pg_dump.... pg_restore...how long does it take?

From
rafikoko
Date:
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.


Re: pg_dump.... pg_restore...how long does it take?

From
Tom Lane
Date:
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

Re: pg_dump.... pg_restore...how long does it take?

From
rafikoko
Date:

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.


Re: pg_dump.... pg_restore...how long does it take?

From
rafikoko
Date:
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.


Re: pg_dump.... pg_restore...how long does it take?

From
rafikoko
Date:
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.


Re: pg_dump.... pg_restore...how long does it take?

From
Tom Lane
Date:
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