Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id 1E969CBE9BF for ; Thu, 15 Dec 2011 08:32:08 -0400 (AST) Received: from moutng.kundenserver.de ([212.227.17.8]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1RbATk-0007jQ-Sm for pgsql-hackers@postgresql.org; Thu, 15 Dec 2011 12:32:07 +0000 Received: from [192.168.1.3] (mail.highperformancepostgresql.com [71.179.240.8]) by mrelayeu.kundenserver.de (node=mreu3) with ESMTP (Nemesis) id 0M6K9X-1QmeRv0fXv-00yCDG; Thu, 15 Dec 2011 13:31:52 +0100 Message-ID: <4EE9E8B7.9010804@2ndQuadrant.com> Date: Thu, 15 Dec 2011 07:31:51 -0500 From: Greg Smith User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111110 Icedove/3.0.11 MIME-Version: 1.0 To: pgsql-hackers@postgresql.org Subject: Re: patch : Allow toast tables to be moved to a different tablespace References: <4E8F1666.2060409@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V02:K0:LvEQMB5wsd23HXSRSkyJG+A8sJgICaBXrApju32hPU8 8W7CAZi23felljpUqwEIMfrwudQY8qlho7BtY5OmifzQ7ac/Om 3swY2Hc+1ENGMxXesLqSgDvg9bEK1cGptJZnqa+OUrsfYundYO BdpFz3N0WGUIbwO5NPuXNejA2mecV6WNm9dhyBrv9ozW0V5Biy +QcBilOgoDtf3qy2SZYwnSbd9TNKNciTKaEZe4e1NBExCs+Sn2 /MRlQTW7QlBnIjC1VmYytzlhSeas2MJtU8h5N3720yEquog1ZP 0oxuZw7eLwbeaWv+jVuY8KwvvtEz2tU6uCbqojMlBxPRovOZ4x R9vdiOoTWGFGNMRAuvn8= X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201112/683 X-Sequence-Number: 199935 On 12/13/2011 12:29 PM, Julien Tachoires wrote: > 2011/12/13 Robert Haas: > >> On Tue, Dec 13, 2011 at 12:02 PM, Julien Tachoires wrote: >> >>> Right, it seems to happen when the destination tablespace is the same >>> as the database's tbs, because, in this case, relation's tbs is set to >>> InvalidOid : >>> src/backend/commands/tablecmds.c line 8342 >>> >>> + rd_rel->reltablespace = (newTableSpace == MyDatabaseTableSpace) ? >>> InvalidOid : newTableSpace; >>> >>> Why don't just asign newTableSpace value here ? >>> >> When a relation is stored in the default tablespace, we always record >> that in the system catalogs as InvalidOid. Otherwise, if the >> database's default tablespace were changed, things would break. >> > OK, considering that, I don't see any way to handle the case raised by Jaime :( > So we have a problem here: there's a case that's messy to handle. And there's really a large issue hanging over this whole patch, which is that it needs a better explanation of what exactly it's going to get used for. Especially if the implementation gets more complicated, we'd want to see a clear reason to use this feature. And that's not really clear. If you can return with an update that perhaps finds a way to work around this OID issue, please re-submit that. And if you can explain some more about where you think this feature is useful, more information on that would be helpful. Since this isn't going to get committed soon, I'm going to mark it returned with feedback for now. -- Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us