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 1niSXZ-0003aB-FT for pgsql-bugs@arkaria.postgresql.org; Sun, 24 Apr 2022 03:04:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1niSXX-0005lA-Sv for pgsql-bugs@arkaria.postgresql.org; Sun, 24 Apr 2022 03:03:59 +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 1niSXX-0005l1-Cw for pgsql-bugs@lists.postgresql.org; Sun, 24 Apr 2022 03:03:59 +0000 Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1niSXQ-0000KR-Rf for pgsql-bugs@lists.postgresql.org; Sun, 24 Apr 2022 03:03:58 +0000 Received: by mail-qt1-x82b.google.com with SMTP id v2so1572380qto.6 for ; Sat, 23 Apr 2022 20:03: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:user-agent; bh=scgjZvnH6UvsCo0MmtQSt4CdDubvm56OCY0luQZ2gI0=; b=KuGxGdRmu03vX0+O8N/peuJzJefEp5I9iTZ3sBA0Ff6cWqyay5Q5iZMG8QydoCpK6Y pt91uCKYfczaM2LIwH1OPfMh1jy/cB3A6lKMjRGulzFILAJeyO+wMPhv0IzB2QoQdxT5 dNnIzCH+SLD64jsVB/B9Ddi5IhWLMukFmQ+eg= 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=scgjZvnH6UvsCo0MmtQSt4CdDubvm56OCY0luQZ2gI0=; b=slpCg2GQ8kpzlCPOsOtLCfbfTEHRNTDY5R9pGVCLWhdOxr9/lyIeVR1tys00HflS2K 0xRKGM/K32RJnEnZ/kBct+Tn6LhyigW4wApD1Lc/xwz9We++XWXX6wMxAiQl9K18fRTg NB4wjasHUeRb1ChXpZ5WPxDhGj8bwwl+LqsmN2l9tP6SFn7PRPEcELgXer+nUwtS+N60 y69ZncHggIAO467HFPhkzIA02sQ0eLsyjncg4NyrpWkFlgjnoYc80dc8fz6aeeEnN+NH TO6caXBb2H53CCB3ZDtlTieI+3gA3hXbKozzYXp29J2DeJRTxOPXaqkgE6qhIVVHRHw5 FcbA== X-Gm-Message-State: AOAM530F4MJtSrei5dAbTlwiVi5p0xfg1da8xiXFX6F2eNshrl9/b68Y 6OtzG/ZjlOtruZsp5vlqK2rT20MAbj6PLw== X-Google-Smtp-Source: ABdhPJyMd9Z6VaJRXinQbGC3dEKWmD3s0ZI96qToqTeLGGpHB4dk0Ozvv4Tf2C48z7IRPtyQ2/F3Ng== X-Received: by 2002:a05:622a:46:b0:2f2:9b12:5375 with SMTP id y6-20020a05622a004600b002f29b125375mr8210481qtw.625.1650769430883; Sat, 23 Apr 2022 20:03:50 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id g81-20020a379d54000000b0069e9f9f740esm3050775qke.100.2022.04.23.20.03.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Apr 2022 20:03:50 -0700 (PDT) Date: Sat, 23 Apr 2022 20:03:47 -0700 From: Noah Misch To: Michael Paquier , Andrey Borodin Cc: 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: <20220424030347.GA1285591@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7E6A0189-0BDC-4760-AA61-32780E8D33D8@yandex-team.ru> 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 Drive-by comment: On Sat, Apr 23, 2022 at 11:02:04AM +0500, Andrey Borodin wrote: > I've removed amcheck from the test and replaced it with a simple IndexOnlyScan. I'm not proposing to commit this test anyway, so I left it in amcheck. > The test reliably fails in 30s or earlier. > > 2022-04-23 10:51:06.872 +05 [36192] 004_cic_standby.pl LOG: statement: select i from tbl where i = 236116; > 2022-04-23 10:51:06.890 +05 [36192] 004_cic_standby.pl ERROR: could not open relation with OID 16671 > 2022-04-23 10:51:06.890 +05 [36192] 004_cic_standby.pl STATEMENT: select i from tbl where i = 236116; > > Adding AEL's seem to solve the problem. 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. 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.