X-Original-To: pgsql-performance-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 53C329FB300 for ; Tue, 22 Aug 2006 23:35:26 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 36491-10 for ; Wed, 23 Aug 2006 02:35:11 +0000 (UTC) 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 AA94F9FB2B6 for ; Tue, 22 Aug 2006 23:35:11 -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 k7N2YxPK014079; Tue, 22 Aug 2006 22:34:59 -0400 (EDT) To: Michael Fuhr cc: "Craig A. James" , pgsql-performance@postgresql.org Subject: Re: Moving a tablespace In-reply-to: <20060823013608.GA60075@winnie.fuhr.org> References: <44EBAC86.7070503@modgraph-usa.com> <20060823013608.GA60075@winnie.fuhr.org> Comments: In-reply-to Michael Fuhr message dated "Tue, 22 Aug 2006 19:36:08 -0600" Date: Tue, 22 Aug 2006 22:34:59 -0400 Message-ID: <14078.1156300499@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=3.816 tagged_above=0 required=5 tests=SPF_HELO_SOFTFAIL, SPF_SOFTFAIL X-Spam-Level: *** X-Archive-Number: 200608/370 X-Sequence-Number: 20555 Michael Fuhr writes: > On Tue, Aug 22, 2006 at 06:16:54PM -0700, Craig A. James wrote: >> Is there a way to move a tablespace to a new location without a >> dump/restore? > The last paragraph of the Tablespaces documentation might be helpful: > http://www.postgresql.org/docs/8.1/interactive/manage-ag-tablespaces.html > I just tested this and it appeared to work, but this hypothetical > DBA might want to wait for others to comment before proceeding. AFAIK it works fine. Shut down postmaster, move tablespace's directory tree somewhere else, fix the symbolic link in $PGDATA/pg_tblspc, start postmaster, update the pg_tablespace entry. There isn't anyplace else in Postgres that knows where that link leads. But if you are running a hot PITR backup, see the caveats in TFM about what will happen on the backup machine. > He might also want to initdb and populate a test cluster and practice > the procedure before doing it for real. "Always mount a scratch monkey" ... regards, tom lane