Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UVSG1-0005rn-2y for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2013 19:55:05 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UVSG0-0001IT-J0 for pgsql-hackers@arkaria.postgresql.org; Thu, 25 Apr 2013 19:55:04 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UVSFz-0001HQ-4L; Thu, 25 Apr 2013 19:55:03 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UVSFw-0006Id-Ng; Thu, 25 Apr 2013 19:55:02 +0000 Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.5/8.14.5) with ESMTP id r3PJsuQ5017039; Thu, 25 Apr 2013 15:54:56 -0400 (EDT) From: Tom Lane To: "anarazel@anarazel.de" cc: Andres Freund , Paul Hinze , pgsql-admin@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [ADMIN] Simultaneous index creates on different schemas cause deadlock? In-reply-to: <7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com> References: <10635.1366910251@sss.pgh.pa.us> <20130425173446.GH11158@awork2.anarazel.de> <14978.1366915821@sss.pgh.pa.us> <7a255af4-951e-4c97-b02b-00eacc3644ce@email.android.com> Comments: In-reply-to "anarazel@anarazel.de" message dated "Thu, 25 Apr 2013 20:57:43 +0200" Date: Thu, 25 Apr 2013 15:54:55 -0400 Message-ID: <17038.1366919695@sss.pgh.pa.us> 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 "anarazel@anarazel.de" writes: > I don't have access to the code ATM an I wonder whether DROP CONCURRENTLY has a similar problem? Depends a bit on how the waiting is done... It's not a problem --- that code doesn't depend on waiting for snapshots to expire, it just checks for other sessions holding locks on the target table. (I also did some experimental testing to verify this.) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers