X-Original-To: pgsql-sql-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 3A80311F653D for ; Tue, 25 Apr 2006 15:13:32 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 59022-09 for ; Tue, 25 Apr 2006 15:13:21 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id DE57511F6083 for ; Tue, 25 Apr 2006 15:13:20 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.6/8.13.6) with ESMTP id k3PIDIhO022841; Tue, 25 Apr 2006 14:13:18 -0400 (EDT) To: Markus Schaber cc: PostgreSQL SQL List Subject: Re: Migrating a Database to a new tablespace In-reply-to: <444E5359.5010704@logix-tt.com> References: <4444D607.1000309@logix-tt.com> <444CA2F5.4030705@logix-tt.com> <444CA971.3000505@logix-tt.com> <444CB7C9.8060307@logix-tt.com> <20060425001553.GM64695@pervasive.com> <444E208C.20901@logix-tt.com> <19435.1145978379@sss.pgh.pa.us> <444E5359.5010704@logix-tt.com> Comments: In-reply-to Markus Schaber message dated "Tue, 25 Apr 2006 18:50:33 +0200" Date: Tue, 25 Apr 2006 14:13:18 -0400 Message-ID: <22840.1145988798@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200604/177 X-Sequence-Number: 24986 Markus Schaber writes: > Tom Lane wrote: >> Instead of assuming anything, why don't you look in the tablespace >> directory and see what's there? A quick "ls -aR" would give more >> information than guessing. > There's plenty of stuff there, 8.8 Gigabytes in total. The question is > how to determine if any of those files are still needed, and how to > migrate them so I can drop that tablespace. Match the subdirectory names against pg_database.oid --- any subdir that doesn't correspond to any live entry in pg_database is junk and can be flushed. Within a valid database's subdirectory, match the file names to that database's pg_class.relfilenode (not oid!) to see if any of them are live. regards, tom lane