Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YIHhs-0006BD-JV for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2015 14:10:28 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1YIHhr-00044h-Gm for pgsql-hackers@arkaria.postgresql.org; Mon, 02 Feb 2015 14:10:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1YIHhq-00044a-EC for pgsql-hackers@postgresql.org; Mon, 02 Feb 2015 14:10:26 +0000 Received: from mail.anarazel.de ([217.115.131.40]) by magus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1YIHhl-0008Q2-N9 for pgsql-hackers@postgresql.org; Mon, 02 Feb 2015 14:10:25 +0000 Received: from intern.anarazel.de (e179149092.adsl.alicedsl.de [85.179.149.92]) (Authenticated sender: andres@anarazel.de) by mail.anarazel.de (Postfix) with ESMTPSA id 91F7D460002; Mon, 2 Feb 2015 15:10:16 +0100 (CET) Date: Mon, 2 Feb 2015 15:10:14 +0100 From: Andres Freund To: Robert Haas Cc: Peter Eisentraut , Michael Paquier , Jim Nasby , PostgreSQL mailing lists Subject: Re: REINDEX CONCURRENTLY 2.0 Message-ID: <20150202141014.GA9201@alap3.anarazel.de> References: <52CF45E8.6090208@nasby.net> <20140827064120.GZ21544@awork2.anarazel.de> <545B8AD2.8030203@gmx.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Pg-Spam-Score: -2.7 (--) 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 2014-11-12 16:11:58 -0500, Robert Haas wrote: > On Wed, Nov 12, 2014 at 4:10 PM, Robert Haas wrote: > > On Thu, Nov 6, 2014 at 9:50 AM, Peter Eisentraut wrote: > >> If REINDEX cannot work without an exclusive lock, we should invent some > >> other qualifier, like WITH FEWER LOCKS. > > > > What he said. > > But more to the point .... why, precisely, can't this work without an > AccessExclusiveLock? And can't we fix that instead of setting for > something clearly inferior? So, here's an alternative approach of how to get rid of the AEL locks. They're required because we want to switch the relfilenodes around. I've pretty much no confidence in any of the schemes anybody has come up to avoid that. So, let's not switch relfilenodes around. I think if we should instead just use the new index, repoint the dependencies onto the new oid, and then afterwards, when dropping, rename the new index one onto the old one. That means the oid of the index will change and some less than pretty grovelling around dependencies, but it still seems preferrable to what we're discussing here otherwise. Does anybody see a fundamental problem with that approach? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers