Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kqgUK-0005d0-4a for pgsql-bugs@arkaria.postgresql.org; Sat, 19 Dec 2020 17:57:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kqgUI-0004ul-4H for pgsql-bugs@arkaria.postgresql.org; Sat, 19 Dec 2020 17:57:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kqgUH-0004ue-Ur for pgsql-bugs@lists.postgresql.org; Sat, 19 Dec 2020 17:57:49 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kqgUB-0002jk-EI for pgsql-bugs@lists.postgresql.org; Sat, 19 Dec 2020 17:57:49 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 0BJHvfKO273958; Sat, 19 Dec 2020 12:57:41 -0500 From: Tom Lane To: Andrey Borodin cc: pgsql-bugs@lists.postgresql.org Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data In-reply-to: <2E712143-97F7-4890-B470-4A35142ABC82@yandex-team.ru> References: <2E712143-97F7-4890-B470-4A35142ABC82@yandex-team.ru> Comments: In-reply-to Andrey Borodin message dated "Sat, 19 Dec 2020 22:13:39 +0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <273956.1608400661.1@sss.pgh.pa.us> Date: Sat, 19 Dec 2020 12:57:41 -0500 Message-ID: <273957.1608400661@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Andrey Borodin writes: > This happens because WaitForLockersMultiple() does not take prepared > xacts into account. Ugh, clearly an oversight. > Meanwhile CREATE INDEX CONCURRENTLY expects that locks are dropped only > when transaction commit is visible. Don't follow your point here --- I'm pretty sure that prepared xacts continue to hold their locks. > PFA draft of a fix. Haven't you completely broken VirtualXactLock()? Certainly, whether the target is a normal or prepared transaction shouldn't alter the meaning of the "wait" flag. In general, I wonder whether WaitForLockersMultiple and GetLockConflicts need to gain an additional parameter indicating whether to consider prepared xacts. It's not clear to me that their current behavior is wrong for all possible uses. regards, tom lane