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@postgresql.org so that your
> message can get through to the mailing list cleanly
>

--
Darren Ferguson