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 1nVUjy-0000wp-3l for pgsql-hackers@arkaria.postgresql.org; Sat, 19 Mar 2022 08:47:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nVUjv-0004Uv-Jx for pgsql-hackers@arkaria.postgresql.org; Sat, 19 Mar 2022 08:47:11 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nVUjv-0004Ul-3J for pgsql-hackers@lists.postgresql.org; Sat, 19 Mar 2022 08:47:11 +0000 Received: from mail-qt1-x836.google.com ([2607:f8b0:4864:20::836]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nVUjs-0004Ax-KS for pgsql-hackers@postgresql.org; Sat, 19 Mar 2022 08:47:09 +0000 Received: by mail-qt1-x836.google.com with SMTP id c4so8568736qtx.1 for ; Sat, 19 Mar 2022 01:47:08 -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=CEMJfrOtBOlBUQt18s5TK8bca1uBepkSFhHjZVWP6GE=; b=MEyeUJBwmK4GeFMIFzb/Bx2HOqKxZpOYrAzxVHELKNNl1qn6u28dsnolKx0D/McqMM nRC+0jPskNnUTLHOR26L/giWg+8XM4yl8HMCPFyXuvoQ9/W16MX2xeKf3i4rsMXahdRi jz7tfVEgiBou9joZEKdGP6pgR78G5OK58933A= 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=CEMJfrOtBOlBUQt18s5TK8bca1uBepkSFhHjZVWP6GE=; b=u1/jSssaiziqMRUUvDf5cnuSPe4egelKVbJJuTb5pT7kS+NdxnKwv/0e26c4nIQORt lW9jkDgyKGW4iJMDztMuvgYnF3KZkMN8KQ9Be6+hXvZMU0DB6oa9S+TZ1WKQBHVD6Vc0 Cn/rGSrndd9RNf35/b25VbhUiMu+2pUwyDnXLBX/sFJwkECZh7dyk95zwaRZ/dqS35YV ixBMTybkZhjOsMzllSm3ZeYdKjNMcXElNKVy8obhR25YGjYV4Q/iBmbRw5HR+ZL1igL7 voZCkZyy8d1pqDE4NqAEIPriP3MrIvSZsXR7ZTSjfucPA7qNbFrkV85JOlL17jfv6lOO hXaQ== X-Gm-Message-State: AOAM533cEy65vt5+7imyAiSJcHVLFU/jxOGVQeIx0KGgfxBMzUdFPvBL Scda/IZ1tkllKvzN1awCN0rOLw== X-Google-Smtp-Source: ABdhPJzTyq0IQd2u81FC4Do0/s7gxZiogSR7A4vhaERBn5c3U0iqAFdvKHOQz5FGCvFEYq6kXCJyTw== X-Received: by 2002:ac8:7d06:0:b0:2e1:d1c4:868 with SMTP id g6-20020ac87d06000000b002e1d1c40868mr9960891qtb.143.1647679627764; Sat, 19 Mar 2022 01:47:07 -0700 (PDT) Received: from rfd.leadboat.com ([2600:1702:a20:5750::2e]) by smtp.gmail.com with ESMTPSA id x21-20020a376315000000b0067d1b191f89sm4947368qkb.68.2022.03.19.01.47.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Mar 2022 01:47:07 -0700 (PDT) Date: Sat, 19 Mar 2022 01:47:04 -0700 From: Noah Misch To: Tom Lane Cc: Thomas Munro , Alexander Lakhin , Andrew Dunstan , pgsql-hackers Subject: Re: Why is src/test/modules/committs/t/002_standby.pl flaky? Message-ID: <20220319084704.GB2822749@rfd.leadboat.com> References: <1609152.1641691036@sss.pgh.pa.us> <3b904d7b-ef84-6f1b-9326-9f88c1374eb8@gmail.com> <5d507424-13ce-d19f-2f5d-ab4c6a987316@gmail.com> <2411751.1641849927@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2411751.1641849927@sss.pgh.pa.us> 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, Jan 10, 2022 at 04:25:27PM -0500, Tom Lane wrote: > Apropos of that, it's worth noting that wait_for_catchup *is* > dependent on up-to-date stats, and here's a recent run where > it sure looks like the timeout cause is AWOL stats collector: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=sungazer&dt=2022-01-10%2004%3A51%3A34 > > I wonder if we should refactor wait_for_catchup to probe the > standby directly instead of relying on the upstream's view. It would be nice. For logical replication tests, do we have a monitoring API independent of the stats collector? If not and we don't want to add one, a hacky alternative might be for wait_for_catchup to run a WAL-writing command every ~20s. That way, if the stats collector misses the datagram about the standby reaching a certain LSN, the stats collector would have more chances.