Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 191F83E3C9D; Sun, 4 Dec 2011 12:41:45 -0400 (AST) Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RXF8K-0002s9-FB; Sun, 04 Dec 2011 16:41:44 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id pB4GfUDd023637; Sun, 4 Dec 2011 11:41:30 -0500 (EST) To: Magnus Hagander cc: Bruce Momjian , PostgreSQL-documentation , PostgreSQL-development Subject: Re: Moving tablespaces In-reply-to: References: <201112041612.pB4GCHt06225@momjian.us> Comments: In-reply-to Magnus Hagander message dated "Sun, 04 Dec 2011 17:22:33 +0100" Date: Sun, 04 Dec 2011 11:41:30 -0500 Message-ID: <23636.1323016890@sss.pgh.pa.us> From: Tom Lane X-Pg-Spam-Score: -3.1 (---) X-Archive-Number: 201112/8 X-Sequence-Number: 7115 Magnus Hagander writes: > And IIRC, we don't actually *use* spclocation anywhere. Just for pg_dump, I think. > How about we > just get rid of them as independents? We could either: > 1) Remove the column. Rely on the symlink. Create a > pg_get_tablespace_location(oid) function, that could be used by > pg_dumpall and friends, that just reads the symlink. Hm, how portable is symlink-reading? If we can actually do that without big headaches, then +1. > 2) Forcibly update the spclocation column when we start the server to > be whatever the symlink points to. That will at least automatically > restore the system to being consistent. -1, running a transaction at that level will be a giant pita. And how would you do it at all on a hot standby slave? regards, tom lane