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 1ngCs4-0005Mh-US for pgsql-hackers@arkaria.postgresql.org; Sun, 17 Apr 2022 21:55:52 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1ngCs3-0007Vs-N6 for pgsql-hackers@arkaria.postgresql.org; Sun, 17 Apr 2022 21:55:51 +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 1ngCs3-0007Vj-Dg for pgsql-hackers@lists.postgresql.org; Sun, 17 Apr 2022 21:55:51 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ngCs1-00045F-RM for pgsql-hackers@lists.postgresql.org; Sun, 17 Apr 2022 21:55:51 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 23HLthIa2162728; Sun, 17 Apr 2022 17:55:43 -0400 From: Tom Lane To: Andres Freund cc: Amit Kapila , Tomas Vondra , pgsql-hackers@lists.postgresql.org Subject: Re: Stabilizing the test_decoding checks, take N In-reply-to: <20220417215203.2wjhsjszxh4htyby@alap3.anarazel.de> References: <1958043.1650129119@sss.pgh.pa.us> <20220417143104.eftldj7d73rqtqoc@alap3.anarazel.de> <20220417143236.lp3hksv2h2z7qn6p@alap3.anarazel.de> <2132311.1650211313@sss.pgh.pa.us> <20220417215203.2wjhsjszxh4htyby@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Sun, 17 Apr 2022 14:52:03 -0700" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2162726.1650232543.1@sss.pgh.pa.us> Date: Sun, 17 Apr 2022 17:55:43 -0400 Message-ID: <2162727.1650232543@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2022-04-17 12:01:53 -0400, Tom Lane wrote: >> It seems likely to me that trying to make a test like this one blind to >> autovacuum/autoanalyze activity will make it less useful, not more so. >> Why is such blindness desirable? > Maybe I misunderstood - I thought you were proposing to prevent > autovacuum by increasing naptime? Won't that precisely blind us to > autovacuum/analyze? Hiding empty xacts happens "very late", so all the > decoding etc still happens. My concern is basically that if we hack the code so it does not report autovacuum activity, that might result in it also not reporting other things that are more interesting. So I think an external method of suppressing test noise due to autovac is more advisable. regards, tom lane