Re: [GENERAL] Copying table to another database.

Поиск
Список
Период
Сортировка
От Wim
Тема Re: [GENERAL] Copying table to another database.
Дата
Msg-id 3D873EA7.6020408@belbone.be
обсуждение исходный текст
Список pgsql-admin

Nigel J. Andrews wrote:

>On Tue, 17 Sep 2002, Wim wrote:
>
>
>>>The next simple but dumb test, which I don't know if you have already tried, is
>>>to check that you can SELECT * FROM pg_* without error.
>>>
>>>
>>>
>>"SELECT * FROM pg_*" gives:
>>ERROR:  Relation "pg_" does not exist
>>
>>
>
>Sorry, I wasn't clear. I meant the pg_* to represent all of the pg_ tables
>taken in turn. To get a list try:
>
>SELECT relname FROM pg_class WHERE relname like 'pg_%' AND relkind = 'r'
>
SELECT relname, relkind from pg_class;

works, but:

SELECT relname FROM pg_class WHERE relname like 'pg_%' AND relkind = 'r';
belbonedb_v2-# ;
server closed the connection unexpectedly
        This probably means the server terminated abnormally
        before or while processing the request.
The connection to the server was lost. Attempting reset: Failed.

>I see in the meantime there's been more messages suggesting the hardware is at
>fault.  I still wouldn't rule that out, especially if you haven't been able to
>properly test these things. Running a second box in parallel once you are
>up and will help show if this is the problem. However, in this regard I'd be
>more inclined to use a replacement system for production, you can extract your
>data alright and should be able to recreate the schema for earlier dumps, and
>to then test the Sparc machine thoroughly. Perhaps even calling Sun to handle
>or help with this.
>
>
>
>



В списке pgsql-admin по дате отправления:

Предыдущее
От: Andrew Sullivan
Дата:
Сообщение: Re: [GENERAL] Still big problems with pg_dump!
Следующее
От: Wim
Дата:
Сообщение: Re: [GENERAL] Still big problems with pg_dump!