Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 0E59018E0E8A for ; Thu, 10 Nov 2011 07:08:43 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 59712-07 for ; Thu, 10 Nov 2011 11:08:37 +0000 (UTC) X-Greylist: delayed 00:06:43.041447 by SQLgrey-1.8.0-rc2 Received: from mail-ey0-f174.google.com (mail-ey0-f174.google.com [209.85.215.174]) by mail.postgresql.org (Postfix) with ESMTP id 0A5CD18E0E89 for ; Thu, 10 Nov 2011 07:08:35 -0400 (AST) Received: by eye27 with SMTP id 27so2247172eye.19 for ; Thu, 10 Nov 2011 03:08:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=oimO1MTjeJO3gQXHw4cz05wuM8vEgwLnDG5z7zsiJEY=; b=vDZAMX39fe68LN2Mg+CV5nEYnsjwjzVAyDvb4aNqIwwvpAHyK/iz84DEpFztf7lh/a MsEMbCPMxfX9SOmjkk00FnZGSVgrHJ7lMMfTm+6hxMl8YSBotke6FYQVRY2GuBK/a+rO FuM+X9oJ6DU+0hDqRdwSzzyRLmCDWiBiyG/bc= Received: by 10.213.28.79 with SMTP id l15mr2033405ebc.90.1320922909578; Thu, 10 Nov 2011 03:01:49 -0800 (PST) Received: from [192.168.10.195] (wlan.dagstuhl.de. [192.76.146.51]) by mx.google.com with ESMTPS id v3sm21542191eej.7.2011.11.10.03.01.46 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 Nov 2011 03:01:48 -0800 (PST) Message-ID: <4EBBAF18.7080102@googlemail.com> Date: Thu, 10 Nov 2011 12:01:44 +0100 From: Thorsten Strufe User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: lost tablespace Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.899 tagged_above=-10 required=5 tests=BAYES_00=-1.9, FREEMAIL_FROM=0.001 X-Spam-Level: X-Archive-Number: 201111/45 X-Sequence-Number: 38639 Hi everybody, sorry, noob here. So we've just started using postgre and right at the start we had a hardware problem with a hard drive failing. We can still start postgre but a tablespace for a db that we don't even need anymore is lost. Now we would think that shouldn't be a problem, we could simply drop that db. postgre, however, doesn't allow us to, but tells us to vacuume the db first. Starting postgre singleuser and trying to run vacuum still gives us the same trouble. Now a naive question: is there any (sane) way to simply get postgre to entirely forget about the broken db - and that's it (dumping the other db and loading it back might not be the best solution, since it's rather large..)? TIA, best, Thorsten syslog-snippet: 2011-11-10 11:05:10 CET LOG: incomplete startup packet 2011-11-10 11:05:10 CET LOG: could not open tablespace directory "pg_tblspc/17488/PG_9.0_201008051": No such file or directory 2011-11-10 11:05:10 CET LOG: could not open tablespace directory "pg_tblspc/18488/PG_9.0_201008051": No such file or directory 2011-11-10 11:05:10 CET LOG: could not open tablespace directory "pg_tblspc/18055/PG_9.0_201008051": No such file or directory 2011-11-10 11:05:10 CET WARNING: database with OID 17546 must be vacuumed within 999999 transactions 2011-11-10 11:05:10 CET HINT: To avoid a database shutdown, execute a database-wide VACUUM in that database. You might also need to commit or roll back old prepared transactions. 2011-11-10 11:05:10 CET LOG: autovacuum launcher started 2011-11-10 11:05:10 CET LOG: database system is ready to accept connections 2011-11-10 11:05:19 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18260": No such file or directory 2011-11-10 11:05:19 CET CONTEXT: automatic vacuum of table "postgres.public.user" 2011-11-10 11:05:19 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18276": No such file or directory 2011-11-10 11:05:19 CET CONTEXT: automatic vacuum of table "postgres.public.task" 2011-11-10 11:05:19 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18298": No such file or directory 2011-11-10 11:05:19 CET CONTEXT: automatic vacuum of table "postgres.public.queue" 2011-11-10 11:05:19 CET ERROR: database is not accepting commands to avoid wraparound data loss in database with OID 17546 2011-11-10 11:05:19 CET HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll back old prepared transactions. 2011-11-10 11:05:28 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18260": No such file or directory 2011-11-10 11:05:28 CET CONTEXT: automatic vacuum of table "postgres.public.user" 2011-11-10 11:05:28 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18276": No such file or directory 2011-11-10 11:05:28 CET CONTEXT: automatic vacuum of table "postgres.public.task" 2011-11-10 11:05:28 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18298": No such file or directory 2011-11-10 11:05:28 CET CONTEXT: automatic vacuum of table "postgres.public.queue" 2011-11-10 11:05:28 CET ERROR: database is not accepting commands to avoid wraparound data loss in database with OID 17546 2011-11-10 11:05:28 CET HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll back old prepared transactions. 2011-11-10 11:05:36 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18260": No such file or directory 2011-11-10 11:05:36 CET CONTEXT: automatic vacuum of table "postgres.public.user" 2011-11-10 11:05:36 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18276": No such file or directory 2011-11-10 11:05:36 CET CONTEXT: automatic vacuum of table "postgres.public.task" 2011-11-10 11:05:36 CET ERROR: could not open file "pg_tblspc/18055/PG_9.0_201008051/11874/18298": No such file or directory 2011-11-10 11:05:36 CET CONTEXT: automatic vacuum of table "postgres.public.queue" 2011-11-10 11:05:36 CET ERROR: database is not accepting commands to avoid wraparound data loss in database with OID 17546 2011-11-10 11:05:36 CET HINT: Stop the postmaster and use a standalone backend to vacuum that database. You might also need to commit or roll back old prepared transactions. ... etc.etc.etc