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 1mF1ux-0004MR-Be for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Aug 2021 22:14:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mF1uP-00059N-Se for pgsql-bugs@arkaria.postgresql.org; Sat, 14 Aug 2021 22:13:41 +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 1mF1uP-00059F-EQ for pgsql-bugs@lists.postgresql.org; Sat, 14 Aug 2021 22:13:41 +0000 Received: from mail-qk1-x72f.google.com ([2607:f8b0:4864:20::72f]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mF1uI-0007PG-RB for pgsql-bugs@lists.postgresql.org; Sat, 14 Aug 2021 22:13:40 +0000 Received: by mail-qk1-x72f.google.com with SMTP id y144so1974363qkb.6 for ; Sat, 14 Aug 2021 15:13:34 -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:user-agent; bh=jWsga513j6NWOhEef9h9NC3akpdKCGBJ743BETv9B4k=; b=CfRsu3pbA71JeAm5ot7Xj7i/SrNSeniIk9xTFTLQGKIbWS+KbNbE3SCyTF5nk9oOPu guaxGUFIfyexvx62z7AIykp4KM0OWVmf0BZc6LpGUvJ1jHpVMjxcqev48EPuzHiMo1RE muMOiE8L9HAx2umPrT38IgW/D5WbDsZBixF48= 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:user-agent; bh=jWsga513j6NWOhEef9h9NC3akpdKCGBJ743BETv9B4k=; b=q/jrWw7gLypxLwXusYzcFMmW3lnn6IxSnzs6BpYaneI6ns3cx5Qbk/hWKqA3RSwADy BmfLDf1JTF1n3qAm3GjHj+BJ5/Rn1/1BogyD5TA9ZPHcbMeiCH1SUkI6MGOJNconbST4 KjY4FegXtveaF8gg/tTXeKQYo3u79VVRO/fJbuVKvpJX/tY5XHERwYfbYxuEYK3xTJ+k WcqAeu71lwJ/LjYgVbFQ83dKhbjTFGDD4ci917GTtLwIA3TwNMlRZZkca8jCvITYOjww K8zc04ilq26ig/XsPZySx9iayiDHsnePJJ/BbIKuMCSqM6n73UZct5ELdbdxUK5if8zn YAiw== X-Gm-Message-State: AOAM5324dQ4NNxofbecnSZNSKwni+YCDfyRW2Lid1d5d70E+WMA2Zz2E m73sELjC1lEvAbz33nLLiYuOiA== X-Google-Smtp-Source: ABdhPJyv6OQV7BmhJ1khTolBKWsu1lk2gmx+yb9LfcjgtnSyAw/ciXdheeZGJWjNXY9v5JIaz4usuA== X-Received: by 2002:a37:91c7:: with SMTP id t190mr9163047qkd.282.1628979212207; Sat, 14 Aug 2021 15:13:32 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::46]) by smtp.gmail.com with ESMTPSA id b12sm2664922qtx.88.2021.08.14.15.13.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Aug 2021 15:13:31 -0700 (PDT) Date: Sat, 14 Aug 2021 15:13:28 -0700 From: Noah Misch To: Andrey Borodin Cc: PostgreSQL mailing lists , Michael Paquier , Tom Lane , Peter Geoghegan Subject: Re: CREATE INDEX CONCURRENTLY does not index prepared xact's data Message-ID: <20210814221328.GA146778@rfd.leadboat.com> References: <20210730184126.GA2018234@gust.leadboat.com> <85D32B53-FB25-4F2F-A253-0D7B26F72881@yandex-team.ru> <341252AE-B633-471E-9FF4-B09FC5D036E2@yandex-team.ru> <20210807221957.GA169359@rfd.leadboat.com> <5E041A70-4946-489C-9B6D-764DF627A92D@yandex-team.ru> <20210808163752.GB23176@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210808163752.GB23176@rfd.leadboat.com> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Aug 08, 2021 at 09:37:52AM -0700, Noah Misch wrote: > On Sun, Aug 08, 2021 at 04:31:07PM +0500, Andrey Borodin wrote: > > Step 1. Test for CIC with regular transactions. > > Step 2. Fix > > Step 3. Test for CIC with 2PC > > Step 4. Part of the fix that I'm sure about > > Step 5. Dubious part of fix... When I applied all five to commit b33259e^ (shortly before the PostgresNode compatibility break) and ran your tests in a loop, I got more 2PC "lacks matching index tuple" within one minute. Here's how I ran the tests: make -j20 && while make -C contrib/amcheck check REGRESS= PROVE_FLAGS=--timer PROVE_TESTS='t/002_cic.pl t/003_cic_2pc.pl' NO_TEMP_INSTALL=1; do date; done Do you see failures with that loop? If so, can you diagnose them? (So far, I've not seen a failure from the 1PC test.) On Thu, Jul 29, 2021 at 10:25:48PM -0400, Noah Misch wrote: > I haven't checked whether other inval message types have the same hazard. I will look into this next. (It probably doesn't explain 2PC failures.)