Re: PG_DUMP too slow...

From: Richard Huxton <dev(at)archonet(dot)com>
To: jerome(at)gmanmi(dot)tv, PostgresGeneral <pgsql-general(at)postgresql(dot)org>
Subject: Re: PG_DUMP too slow...
Date: 2003-05-09 12:08:22
Message-ID: 200305091308.22133.dev@archonet.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Dennis Gearon 2003-05-09 15:06:22 Re: pg_dump options and perhaps 'Enhancement request'
Previous Message Martin Marques 2003-05-09 11:36:59 Re: informix to postgres tools?