Re: Copying table to another database.
От | Wim |
---|---|
Тема | Re: Copying table to another database. |
Дата | |
Msg-id | 3D8700E2.8040304@belbone.be обсуждение исходный текст |
Ответ на | Re: Copying table to another database. ("Nigel J. Andrews" <nandrews@investsystems.co.uk>) |
Ответы |
Re: Copying table to another database.
|
Список | pgsql-general |
Hi Nigel, Thanx for the response... Nigel J. Andrews wrote: >On Tue, 17 Sep 2002, Wim wrote: > > > >>Anyone knows how to copy a table to another database? >> >> > > >Use the the COPY command: > >Name >COPY -- copy data between files and tables > >Synopsis > >COPY [ BINARY ] table [ WITH OIDS ] > FROM { 'filename' | stdin } > [ [USING] DELIMITERS 'delimiter' ] > [ WITH NULL AS 'null string' ] > >COPY [ BINARY ] table [ WITH OIDS ] > TO { 'filename' | stdout } > [ [USING] DELIMITERS 'delimiter' ] > [ WITH NULL AS 'null string' ] > > >Or, bearing in mind your problem, > > pg_dump -t <tablename> ... > > >For your real problem, it sounds like it's the system tables causing you >problems. You say you tried REINDEX, that was REINDEX DATABASE <dbname> FORCE >presumably. > Yep, that's right... > >It is somewhat worrying that the same problem has reoccured. You checked your >hard disk but what about memory? > Checked with vmstat: kthr memory page disk faults cpu r b w swap free re mf pi po fr de sr m1 m1 m1 m2 in sy cs us sy id 0 0 0 658872 156016 0 0 0 0 0 0 0 0 0 0 0 402 9 18 0 0 100 0 0 0 658872 155216 321 0 2849 10 10 0 0 0 0 0 0 416 353 30 79 3 18 0 0 0 657392 159440 317 58 2207 0 0 0 0 0 0 0 0 457 1781 93 92 7 1 0 0 0 657880 166720 342 60 2871 40 40 0 0 0 0 0 0 438 1073 73 89 7 4 0 0 0 658872 167392 376 0 3200 2 2 0 0 0 0 0 0 408 438 35 94 2 3 0 0 0 658872 169096 369 0 2534 0 0 0 0 0 0 0 0 412 401 43 91 5 4 0 0 0 658872 168984 361 0 2968 2 2 0 0 0 0 0 0 414 386 47 90 3 6 0 0 0 658872 169432 81 0 378 0 0 0 0 0 0 0 0 406 94 26 21 1 78 0 0 0 658872 169424 0 0 0 0 0 0 0 0 0 0 0 406 12 23 0 0 100 0 0 0 658872 169296 15 55 0 2 2 0 0 0 0 0 0 409 88 25 1 1 98 0 0 0 658872 168808 0 0 0 0 0 0 0 0 0 0 0 402 9 18 0 0 100 > >pg_dumpall fails but what about just pg_dump on the individual DBs? > pg_dump fails on one database... other DB's are dumped... > >Is it a production system? If it continues to cause problems what about >considering bringing someone in to investigate? > > Indeed, it's a production system. What do you mean by bringing someone in to investigate? Someone from Postgres? PS: I have some debugging output... > > > Thnx for your help! Wim
В списке pgsql-general по дате отправления: