Thread: PG_DUMP too slow...
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 ......................................... TIA
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
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.. > > 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.
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