Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 78D72AD3D78 for ; Wed, 29 Feb 2012 16:55:32 -0400 (AST) Received: from locust.cns.ipv6.vt.edu ([2001:468:c80:210f:211:43ff:fee7:4af5] helo=locust.cns.vt.edu) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S2qYa-00007W-2o for pgsql-admin@postgresql.org; Wed, 29 Feb 2012 20:55:30 +0000 Received: by locust.cns.vt.edu (Postfix, from userid 986) id 5AE12118DE6; Wed, 29 Feb 2012 15:55:13 -0500 (EST) Date: Wed, 29 Feb 2012 15:55:13 -0500 From: Ray Stell To: pgsql-admin@postgresql.org Subject: re-create information_schema Message-ID: <20120229205513.GA761@cns.vt.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.17 (2007-11-01) X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201202/126 X-Sequence-Number: 39186 on rebuilding the information_schema: http://www.postgresql.org/docs/9.1/static/release-9-1-2.html ... Since the view definition is installed by initdb, merely upgrading will not fix the problem. If you need to fix this in an existing installation, you can (as a superuser) drop the information_schema schema then re-create it by sourcing SHAREDIR/information_schema.sql. (Run pg_config --sharedir if you're uncertain where SHAREDIR is.) This must be repeated in each database to be fixed. The right thing to do here is drop cascade, correct? No harm done with that? doodah=# drop schema information_schema; ERROR: cannot drop schema information_schema because other objects depend on it DETAIL: table information_schema.sql_sizing_profiles depends on schema information_schema table information_schema.sql_sizing depends on schema information_schema ... view information_schema.check_constraint_routine_usage column constraint_name depends on type information_schema.sql_identifier and 138 other objects (see server log for list) HINT: Use DROP ... CASCADE to drop the dependent objects too. Thanks.