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 <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1m4qgH-0004mp-Sb
	for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Jul 2021 20:13:01 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-bugs-owner+archive@lists.postgresql.org>)
	id 1m4qgE-00027Y-J6
	for pgsql-bugs@arkaria.postgresql.org; Sat, 17 Jul 2021 20:12:58 +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 <noah@leadboat.com>)
	id 1m4qgE-00027Q-59
	for pgsql-bugs@lists.postgresql.org; Sat, 17 Jul 2021 20:12:58 +0000
Received: from mail-il1-x133.google.com ([2607:f8b0:4864:20::133])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128)
	(Exim 4.92)
	(envelope-from <noah@leadboat.com>)
	id 1m4qg8-00065P-JA
	for pgsql-bugs@lists.postgresql.org; Sat, 17 Jul 2021 20:12:57 +0000
Received: by mail-il1-x133.google.com with SMTP id w1so11678158ilg.10
        for <pgsql-bugs@lists.postgresql.org>;
 Sat, 17 Jul 2021 13:12:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=leadboat.com; s=google;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-disposition:in-reply-to;
        bh=D9CEW61M799quzgn70gVluqsJD/6rMX0bXroPhwPZ7A=;
        b=B+p2S0Uel96PbsEa9eZC6bCTDPnAn+6IZJ2my4TZG/k9Z94Y5xIBZASaESw8pLg/8A
         D6UAAdN9Md0C7gcBReW4hEMgSCP17k/5orJYlFNG17VnFtPKcPR2z73h6A21nAM6LjuM
         TLlNu5UqX/ESBAEiQ6sb7tR974gWEgRgtYRJ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-disposition:in-reply-to;
        bh=D9CEW61M799quzgn70gVluqsJD/6rMX0bXroPhwPZ7A=;
        b=gq0/0yYc8Y7DDloZaF1AkZs6QDIw0Ac5MqeqgjA8pQOOVfnHDRcYSz+NGsBLu9Ak0r
         ubc1eW8okc/xicZTjapDSMx3VxuZ82+sch5ctM64bHuWuVG5dDb18b9N4KQ2CTYmw+bW
         PfWSwRxfNlatQsS0TehlqyOiaNrfowXWdm9tSPuMcdVrR3mnOYyVdZIYJxoaeWUXQYNX
         jFjlPVJIna2mwbrGxSnDJ8sV+o29Vfqmr96M+jiSjPQorr+3KmHq71l/lIsStW8OBKv8
         AcPqTNPfbkVqU2F4g4bukH4tnDsIsuweIwcL03mi+1PyC26QV29KjxXTxdTKeqD7L+/q
         I6HQ==
X-Gm-Message-State: AOAM530w5WoD1/0wZEzNKD5EXgc7vcdZb581VdW9bSFCzpSRgMVrjunZ
	4cfQ34hcwdn2wV37M+NhhFaJew==
X-Google-Smtp-Source: 
 ABdhPJzy2XhuuV1jv8ZdrewcvoXMOWjXqg82qcDHMVS1IpxgnFgFw+Uz7ht3cgGI9J9gS0TgVHp0yw==
X-Received: by 2002:a92:ac0b:: with SMTP id r11mr10742083ilh.44.1626552770631;
        Sat, 17 Jul 2021 13:12:50 -0700 (PDT)
Received: from gust.leadboat.com ([172.243.183.102])
        by smtp.gmail.com with ESMTPSA id
 p25sm7805445ioj.18.2021.07.17.13.12.45
        (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
        Sat, 17 Jul 2021 13:12:50 -0700 (PDT)
Date: Sat, 17 Jul 2021 16:12:40 -0400
From: Noah Misch <noah@leadboat.com>
To: Andrey Borodin <x4mmm@yandex-team.ru>
Cc: Michael Paquier <michael@paquier.xyz>, Tom Lane <tgl@sss.pgh.pa.us>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data
Message-ID: <20210717201240.GA874334@gust.leadboat.com>
References: <273957.1608400661@sss.pgh.pa.us>
 <X+A1M1HajC+knVDz@paquier.xyz>
 <FD04942E-BC4E-42FE-82DF-75D28E3093AC@yandex-team.ru>
 <2C1B82E7-B50C-470C-AE10-794ED2A7A64E@yandex-team.ru>
 <20210117072454.GA1709971@rfd.leadboat.com>
 <EF4A43BD-C62C-429B-94EE-9303A1321F47@yandex-team.ru>
 <20210124022743.GA2270535@rfd.leadboat.com>
 <74C78048-70E8-4356-8F10-6370C37136C8@yandex-team.ru>
 <9C782C9D-D53E-4154-B910-46F062A9AE9B@yandex-team.ru>
 <01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <01824242-AA92-4FE9-9BA7-AEBAFFEA3D0C@yandex-team.ru>
List-Id: <pgsql-bugs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-bugs@lists.postgresql.org>
List-Owner: <mailto:pgsql-bugs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-bugs>
Archived-At: 
 <https://www.postgresql.org/message-id/20210717201240.GA874334%40gust.leadboat.com>
Precedence: bulk

On Sat, Jul 17, 2021 at 10:01:00PM +0500, Andrey Borodin wrote:
> Sorry to say that, but $subj persists. Here's a simple reproduction.

> The problem is WaitForLockersMultiple() gathers running vxids and 2pc xids. Then it waits, but if vxid is converted to 2pc it fails to wait.

That makes sense.

> To fix it we can return locking xids along with vxids from GetLockConflicts() like in attached diff. But this approach seems ugly.

Suppose some transaction has a vxid but no xid.  Shortly after
GetLockConflicts(), it acquires an xid, modifies the table, and issues PREPARE
TRANSACTION.  Could that cause a corrupt index even with this diff?