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
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? |