Re: Copying table to another database.

Maybe a bug in the version you are using as it works fine on the boxes we
use as shown below

SELECT relname FROM pg_class WHERE relname like 'pg_%' AND relkind = 'r';

Works fine on the box we use

oss=> SELECT relname FROM pg_class WHERE relname like 'pg_%' AND relkind =
'r';
relname
----------------
pg_aggregate
pg_am
pg_amop
pg_amproc
pg_attrdef
pg_attribute
pg_class
pg_database
pg_description
pg_group
pg_index
pg_inherits
pg_language
pg_largeobject
pg_listener
pg_opclass
pg_operator
pg_proc
pg_relcheck
pg_rewrite
pg_shadow
pg_statistic
pg_trigger
pg_type
(24 rows)

oss=> select version();
version
-------------------------------------------------------------
PostgreSQL 7.2.1 on i686-pc-linux-gnu, compiled by GCC 2.96
(1 row)

oss=>

On Tue, 17 Sep 2002, Wim wrote:

>
>
> 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.
> >
> >
> >
> >
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 3: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
Darren Ferguson