Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YHGpO-0006lw-Tq for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jan 2015 19:02:03 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YHGpN-00055W-6i for pgsql-hackers@arkaria.postgresql.org; Fri, 30 Jan 2015 19:02:01 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YHGpL-00055P-FA for pgsql-hackers@postgresql.org; Fri, 30 Jan 2015 19:01:59 +0000 Received: from mx-out.zmailcloud.com ([192.198.85.98] helo=mx-out-1.zmailcloud.com) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YHGpD-0002lk-7u for pgsql-hackers@postgresql.org; Fri, 30 Jan 2015 19:01:57 +0000 Received: from smtp.01.com (smtp.01.com [10.10.0.43]) by mx-out-1.zmailcloud.com (Postfix) with ESMTP id 482F0564215; Fri, 30 Jan 2015 13:01:50 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 4009BA033B; Fri, 30 Jan 2015 13:01:50 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnZz2jtJ2qhh; Fri, 30 Jan 2015 13:01:50 -0600 (CST) Received: from smtp.01.com (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id 12E91A037E; Fri, 30 Jan 2015 13:01:50 -0600 (CST) Received: from localhost (localhost [127.0.0.1]) by smtp-out-1.01.com (Postfix) with ESMTP id E79AFA034F; Fri, 30 Jan 2015 13:01:49 -0600 (CST) X-Virus-Scanned: amavisd-new at smtp-out-1.01.com Received: from smtp.01.com ([127.0.0.1]) by localhost (smtp-out-1.01.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dXG8mEKtt-Or; Fri, 30 Jan 2015 13:01:49 -0600 (CST) Received: from [172.47.23.103] (50-0-89-53.dsl.dynamic.fusionbroadband.com [50.0.89.53]) by smtp-out-1.01.com (Postfix) with ESMTPSA id 4DD25A033B; Fri, 30 Jan 2015 13:01:49 -0600 (CST) Message-ID: <54CBD519.8030502@agliodbs.com> Date: Fri, 30 Jan 2015 11:01:45 -0800 From: Josh Berkus Organization: PostgreSQL Experts Inc. User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Stephen Frost , Robert Haas CC: "pgsql-hackers@postgresql.org" Subject: Re: tablespaces inside $PGDATA considered harmful References: <20150130171920.GJ3854@tamriel.snowman.net> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org On 01/30/2015 09:19 AM, Stephen Frost wrote: > * Robert Haas (robertmhaas@gmail.com) wrote: >> Given all this, it seems like a good idea to at least give a warning >> if somebody tries to create a tablespace instead the data directory. > > A warning seems like a good idea. I actually thought we *did* prevent > it.. > >> Arguably, we should prohibit it altogether, but there are obviously >> people that want to do it, and there could even be somewhat valid >> reasons for that, like wanting to set per-tablespace settings >> differently for different tablespaces. Possibly we should prohibit it >> anyway, or maybe there should be an option to create a tablespace >> whose directory is a real directory, not a symlink. So then: >> >> CREATE TABLESPACE foo LOCATION '/home/rhaas/pgdata/pg_tblspc/foo'; >> >> ...would fail, but if you really want a separate tablespace inside the >> data directory, we could allow: >> >> CREATE TABLESPACE foo NO LOCATION; >> >> ...which would just create a bare directory where the symlink would normally go. > > I actually really like this 'NO LOCATION' idea. Are there reasons why > that would be difficult or ill-advised to do? > > I could see the NO LOCATION approach being useful for migrating between > systems, in particular, or a way to have pg_basebackup work that doesn't > involve having to actually map all the tablespaces... I like this idea too. And it would make tablespaces more manageable for people who are using them for reasons other than putting them on different disks. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers