Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XmOP2-0003bu-UE for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Nov 2014 14:51:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XmOP1-0003bg-UH for pgsql-hackers@arkaria.postgresql.org; Thu, 06 Nov 2014 14:51:11 +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 1XmOP0-0003Zk-J1 for pgsql-hackers@postgresql.org; Thu, 06 Nov 2014 14:51:10 +0000 Received: from mout.gmx.net ([212.227.15.18]) by magus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XmOOs-0003e9-Ff for pgsql-hackers@postgresql.org; Thu, 06 Nov 2014 14:51:09 +0000 Received: from auth2-smtp.messagingengine.com ([66.111.4.228]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MRXSK-1XbUIV1UCG-00Sh4Z for ; Thu, 06 Nov 2014 15:50:59 +0100 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailauth.nyi.internal (Postfix) with ESMTP id 12DD620E04 for ; Thu, 6 Nov 2014 09:50:58 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 06 Nov 2014 09:50:58 -0500 X-Sasl-enc: AeD+QLH7jHAX5FpbzOqgIFM8UR9LSYoP+Ve7d4SQX0EU 1415285457 Received: from jesse.mybdev.com (unknown [204.145.120.11]) by mail.messagingengine.com (Postfix) with ESMTPA id C27A56800B8; Thu, 6 Nov 2014 09:50:57 -0500 (EST) Message-ID: <545B8AD2.8030203@gmx.net> Date: Thu, 06 Nov 2014 09:50:58 -0500 From: Peter Eisentraut User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Michael Paquier , Andres Freund CC: Jim Nasby , PostgreSQL mailing lists Subject: Re: REINDEX CONCURRENTLY 2.0 References: <52CF45E8.6090208@nasby.net> <20140827064120.GZ21544@awork2.anarazel.de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:5GuWor1lyOpwTzyM6Bdf6NspHml7W9Ww0VeyF1HglXgUyPtUOJG f/6d8ufJEr8fyOGvlHGa8FTzjemN1gQop5WbCjYNf2LwRU6hXt9kmJV9ELdoK45TAciI0Ux 8/1TmIXlWAZgGRLG6ziX5KEv/ZcD+SIMDtpeJG2SXHCH6RPl9DOkh9Du32IkYm+eTmD5ZVk JY0pz6qb47F1DCD311j9g== X-UI-Out-Filterresults: notjunk:1; X-Pg-Spam-Score: -1.0 (-) 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 10/1/14 3:00 AM, Michael Paquier wrote: > - Use of AccessExclusiveLock when swapping relfilenodes of an index and > its concurrent entry instead of ShareUpdateExclusiveLock for safety. At > the limit of my understanding, that's the consensus reached until now. I'm very curious about this point. I looked through all the previous discussions, and the only time I saw this mentioned was at the very beginning when it was said that we could review the patch while ignoring this issue and fix it later with MVCC catalog access. Then it got very technical, but it was never explicitly concluded whether it was possible to fix this or not. Also, in the thread "Concurrently option for reindexdb" you pointed out that requiring an exclusive lock isn't really concurrent and proposed an option like --minimum-locks. I will point out again that we specifically invented DROP INDEX CONCURRENTLY because holding an exclusive lock even briefly isn't good enough. If REINDEX cannot work without an exclusive lock, we should invent some other qualifier, like WITH FEWER LOCKS. It's still useful, but we shouldn't give people the idea that they can throw away their custom CREATE INDEX CONCURRENTLY + DROP INDEX CONCURRENTLY scripts. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers