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 1nirBi-0000Ld-Jy for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Apr 2022 05:23:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nirBh-0006Tw-9L for pgsql-bugs@arkaria.postgresql.org; Mon, 25 Apr 2022 05:23:05 +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 1nirBh-0006Tn-0l for pgsql-bugs@lists.postgresql.org; Mon, 25 Apr 2022 05:23:05 +0000 Received: from mail-oa1-x32.google.com ([2001:4860:4864:20::32]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nirBc-0003kA-KD for pgsql-bugs@lists.postgresql.org; Mon, 25 Apr 2022 05:23:04 +0000 Received: by mail-oa1-x32.google.com with SMTP id 586e51a60fabf-e5e433d66dso14971123fac.5 for ; Sun, 24 Apr 2022 22:23:00 -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=TiHZhH88+WbgrHXbn1dLNA3EEBwU+lcgcIGNZHuXyR0=; b=DFHP272kRzUNHOXUb9wvJr/V0dLaxRalFFt38oz9pF4OPQzDRh2yHxIWwBd1n5koOw zAKZur9UKpg4lFT9sW0BW9R7EvAG+T14EdfuXjrlRWgPA+SpXPUaz75Hw7eKjUdUNqr2 3Yj1NRQhlwjdL2l0CcHsqDZd5l2vu7NylUWyg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TiHZhH88+WbgrHXbn1dLNA3EEBwU+lcgcIGNZHuXyR0=; b=viClf+YKXTzUGHfYgWLVcBAsAF3hKZBpoNDCGrNPt+5gUr1dFnABGnoEmwn5bA9Fn2 yNMiDOaO6I39ptvEB5U1vlstQeG+k+ZrrmHqMZL+b/D5WYczqkSyR1q6HqFuDdfAglwf hCY42JaBQjeea2PLSNsGSnDP0FBHQP0/IYLn3096V9QCdwDrNHXflGiUunTfzJYqac8s +nLdkPElWMRXeTXtUQviGfgzMAomFnjxXr2meQMIFJUBFHviN4uSKegFOs3AoncNyrsC GSCy6mtY1fjqVvKfaaiTM6ZEbeUdNanJ3q8JATbIAqSLUEvV2IVRr97v5BiQ3cT49aOp c8IA== X-Gm-Message-State: AOAM530YlVnEdzzlg0VKbXPQxwRUFfJLbVa5zQwsGV9MZOp0u9oRsZdu JvEKDR7EfkdfJxfuHp8uIyDHTKQJgrrNZA== X-Google-Smtp-Source: ABdhPJzkd9heZ803xs/1aNAwmtvK0Tzr3xuCxlItSfyXMS6XlyIUNIdMcYbr9yi1pOzMR7dSQb1ZDA== X-Received: by 2002:a05:6870:15c2:b0:e8:1f87:155b with SMTP id k2-20020a05687015c200b000e81f87155bmr5825101oad.27.1650864178336; Sun, 24 Apr 2022 22:22:58 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id e16-20020a4a9b50000000b0035e5b5acc04sm1907874ook.24.2022.04.24.22.22.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Apr 2022 22:22:57 -0700 (PDT) Date: Sun, 24 Apr 2022 22:22:55 -0700 From: Noah Misch To: Michael Paquier Cc: Andrey Borodin , Andres Freund , Ben Chobot , Peter Geoghegan , PostgreSQL mailing lists Subject: Re: BUG #17401: REINDEX TABLE CONCURRENTLY creates a race condition on a streaming replica Message-ID: <20220425052255.GA1360718@rfd.leadboat.com> References: <04D2D137-102E-400D-B66B-C073C27A1327@yandex-team.ru> <20220211001240.47idtavhfyzi4aa3@alap3.anarazel.de> <29311A7B-240A-451A-9DC8-4909A0FEAE12@yandex-team.ru> <5ABDE9D8-D09C-4281-9F84-BF73A865A726@yandex-team.ru> <7E6A0189-0BDC-4760-AA61-32780E8D33D8@yandex-team.ru> <20220424030347.GA1285591@rfd.leadboat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon, Apr 25, 2022 at 02:11:26PM +0900, Michael Paquier wrote: > On Sat, Apr 23, 2022 at 08:03:47PM -0700, Noah Misch wrote: > > If this thread proceeds with the current LogAccessExclusiveLock() design, I > > think it must include a way to disable the new behavior. That requirement > > would apply to any design that delays standby WAL apply in a way that > > hot_standby_feedback can't mitigate. We have the vacuum_truncate reloption > > because AEL is disruptive to standby freshness. Adding a new kind of > > unavoidable AEL would be similarly-painful. > > I am not sure that we should add more reloptions that bypass AEL > requirements FWIW, because the standby would still be opened to cache > errors if you don't log something, would it not? Correct. Even so, a mandatory AEL when replaying CIC would be worse. > > It would nicer to fix this such that, with hot_standby_feedback, the fix > > delays CIC on the primary instead of delaying apply on the standby. If that's > > too hard, AEL plus option-to-disable sounds fine. > > Perhaps. Still, that would be mostly what WaitForOlderSnapshots() > already does, except that we'd roughly just use the limitXmin from the > snapshot of the transaction currently running? I don't know.