Re: PG_DUMP too slow...

Started by Richard Huxtonalmost 23 years ago3 messagesgeneral
Jump to latest
#1Richard Huxton
dev@archonet.com

On Friday 09 May 2003 7:08 pm, jerome wrote:

im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump behaves
like this... hheehhe

im working on a 4 Processor , RH7.3.. w/ postgresql-7.2.1-5 sitting on
it...

can someone tell me what happened?

btw i tried to place a -v option these are the outputs..

pg_dump: saving database definition
pg_dump: last built-in oid is 16554
pg_dump: reading user-defined types
pg_dump: reading user-defined functions
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined tables
.........................................

1. Can you give us a copy of the precise command-line you are using and also a
select count(*) and \dt on the table in question?

2. Does this problem happen only on this table, or all tables?

3. Does this happen when dumping schema only (--schema-only)?

I do seem to remember some bug-fix in pg_dump in the 7.2 series, might be
worth checking the release notes section of the online manuals.
--
Richard Huxton

#2Richard Huxton
dev@archonet.com
In reply to: Richard Huxton (#1)

On Friday 09 May 2003 9:52 pm, jerome wrote:

On Friday 09 May 2003 18:27, Richard Huxton wrote:

On Friday 09 May 2003 7:08 pm, jerome wrote:

im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump
behaves like this... hheehhe

1. Can you give us a copy of the precise command-line you are using and
also a select count(*) and \dt on the table in question?

SELECT count(*) from dc_teksbak ;
count
-------
2
(1 row)

i have 717 tables...

2. Does this problem happen only on this table, or all tables?

i tried it with other tables it works reacts the same...
im dumping the table..

pg_dump mydb -t dc_teksbak > dc.out

Well, the options are supposed to go before the database name, but pg_dump
should cope. Very odd.

Assuming you can select the contents of dc_teksbak I think we can rule out any
problems with the database itself.

Some things it might be worth checking/trying (in this order I'd suggest):
1. Make sure you don't have an old installation with an old pg_dump (pg_dump
--version)
2. Try with --data-only option
3. Try with --schema-only option
4. Make sure no other transactions are active. This shouldn't matter, but I'm
trying to rule things out.
5. Restart the postmaster (with pg_ctl)
6. Create a new test database, make sure you can dump from that.

--
Richard Huxton

#3jerome
jerome@gmanmi.tv
In reply to: Richard Huxton (#1)

On Friday 09 May 2003 18:27, Richard Huxton wrote:

On Friday 09 May 2003 7:08 pm, jerome wrote:

im tried to dump a table with 10 rows...
its like taking me 6 years.. did i do something bad that pg_dump behaves
like this... hheehhe

im working on a 4 Processor , RH7.3.. w/ postgresql-7.2.1-5 sitting on
it...

can someone tell me what happened?

btw i tried to place a -v option these are the outputs..

pg_dump: saving database definition
pg_dump: last built-in oid is 16554
pg_dump: reading user-defined types
pg_dump: reading user-defined functions
pg_dump: reading user-defined aggregate functions
pg_dump: reading user-defined operators
pg_dump: reading user-defined tables
.........................................

1. Can you give us a copy of the precise command-line you are using and
also a select count(*) and \dt on the table in question?

SELECT count(*) from dc_teksbak ;
count
-------
2
(1 row)

i have 717 tables...

2. Does this problem happen only on this table, or all tables?

i tried it with other tables it works reacts the same...

im dumping the table..

pg_dump mydb -t dc_teksbak > dc.out

3. Does this happen when dumping schema only (--schema-only)?

no. im dumping the schema and data..

Show quoted text

I do seem to remember some bug-fix in pg_dump in the 7.2 series, might be
worth checking the release notes section of the online manuals.