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 1pvKNk-0007mf-1s for pgsql-hackers@arkaria.postgresql.org; Sat, 06 May 2023 16:03:36 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pvKNh-0002MD-Es for pgsql-hackers@arkaria.postgresql.org; Sat, 06 May 2023 16:03:33 +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 1pvKNh-0002M3-3K for pgsql-hackers@lists.postgresql.org; Sat, 06 May 2023 16:03:33 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pvKNe-000sc4-6c for pgsql-hackers@lists.postgresql.org; Sat, 06 May 2023 16:03:31 +0000 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-3f195b164c4so19435735e9.1 for ; Sat, 06 May 2023 09:03:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683389007; x=1685981007; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=WZbdGS+90MFGT2xCECSpqNlpecM46vqygP+9X0tXU6Y=; b=fq1PFAJr4rvmxWJPTK9OVeNBk8zb5iTFXyODt5OzhhrApyEBuv9g/2yt8iYJiG26MK OFvGaLDgpu7KLHTQGN28XLNHqU+ZuM+nae4yTmcuo/kQnuMjENmqXtCHuLuJsOWJ7elS DI8lCixG0XivT2vbaYnylCJDRA83VJ865MPvPrZ8Al52WIJArXx1WHGsVG7eWE3Lr3bb 31zzGbaRxeBwT8gNs/B0XaeVvyyupvu8e7oCGLx3sxZMy3LBfjVeCKdOegJyf3w+OLCN qL7/5EimEMuwOa7Lxwt/n8lHDw9xRO06btb7FCfFwcQK9Z2P8/Xo7f1oxfitp2HM8ofN HO7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683389007; x=1685981007; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=WZbdGS+90MFGT2xCECSpqNlpecM46vqygP+9X0tXU6Y=; b=K5Ckev6h2G5Ixqiv5P4Ejar4w8RCWoM/sRBcXxnCk1f/A+eUjtJAgaAJKxAyXq/1tc IiQQ+/nVAL8rbQs22cW1axSlLYS8xt1JatxsuQkiXAWS5uWYDpJF+hRalbkXFGBH4Wei CwXNe5VwCMVmK8Y6ft1VK/8jl7hAAnAZGAbh/ZuIunSzU4JJgbFGmiNjLRCQ+BkPpSPO 3X9qwmfHw+bpryRqyxC/L5IWiGHE/D+/6BuvC29Q7Pn/2zrKvkbbhWUovEZCC75IRON2 5Yte6pnxd59d7CU/VPxZitiBr/AUTo65OHAG8F8Z2PlPWOYhzvDbqI11i+TUVqVNzFd0 fxhA== X-Gm-Message-State: AC+VfDx1wR4rxKmVsPDR3OnK+GtFSGNADKOemYTZWyI/SMhShYDL1D+5 /IsG0ibALcNUy8pnCd2NYMY= X-Google-Smtp-Source: ACHHUZ5IiVb6fcpmc8pj7KBSix7H60CJVtbWqSsh6F8QE6DEkOSS+Hlhi/cphwhKv/PZn3X4hQOwDQ== X-Received: by 2002:a05:600c:292:b0:3f1:6f44:ff3a with SMTP id 18-20020a05600c029200b003f16f44ff3amr3511452wmk.13.1683389007407; Sat, 06 May 2023 09:03:27 -0700 (PDT) Received: from [192.168.8.198] ([54.239.6.185]) by smtp.gmail.com with ESMTPSA id k17-20020adfe3d1000000b00301a351a8d6sm5807466wrm.84.2023.05.06.09.03.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 06 May 2023 09:03:26 -0700 (PDT) Message-ID: <7e5f41be-ec0f-b6f2-2e2a-60fd5648ee84@gmail.com> Date: Sat, 6 May 2023 18:02:10 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Add two missing tests in 035_standby_logical_decoding.pl To: Amit Kapila Cc: vignesh C , "Yu Shi (Fujitsu)" , PostgreSQL Hackers References: <2fefa454-5a70-2174-ddbf-4a0e41537139@gmail.com> <6711e200-0d5c-98c3-ba39-7d64a6936f7a@gmail.com> <2c544b9f-419d-d18e-47be-f3d6f3d24e4e@gmail.com> <3576f684-718d-ddd6-f4b0-f8ad64ad3330@gmail.com> <2894687f-141d-85a9-e8c3-2151e5b7e662@gmail.com> Content-Language: en-US From: "Drouvot, Bertrand" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 5/6/23 3:28 PM, Amit Kapila wrote: > On Sat, May 6, 2023 at 1:52 PM Drouvot, Bertrand > wrote: >> >> There is 2 runs with this extra info in place: >> >> A successful one: https://cirrus-ci.com/task/6528745436086272 >> A failed one: https://cirrus-ci.com/task/4558139312308224 >> > > Thanks, I think I got some clue as to why this test is failing > randomly. Great, thanks! > Observations: > ============ > 1. In the failed run, the KeepLogSeg(), reduced the _logSegNo to 3 > which is the reason for the failure because now the standby won't be > able to remove/recycle the WAL file corresponding to segment number 3 > which the test was expecting. Agree. > 2. We didn't expect the KeepLogSeg() to reduce the _logSegNo because > all logical slots were invalidated. However, I think we forgot that > both standby and primary have physical slots which might also > influence the XLogGetReplicationSlotMinimumLSN() calculation in > KeepLogSeg(). Oh right... > Next steps: > ========= > 1. The first thing is we should verify this theory by adding some LOG > in KeepLogSeg() to see if the _logSegNo is reduced due to the value > returned by XLogGetReplicationSlotMinimumLSN(). Yeah, will do that early next week. > 2. The reason for the required file not being removed in the primary > is also that it has a physical slot which prevents the file removal. Yeah, agree. But this one is not an issue as we are not checking for the WAL file removal on the primary, do you agree? > 3. If the above theory is correct then I see a few possibilities to > fix this test (a) somehow ensure that restart_lsn of the physical slot > on standby is advanced up to the point where we can safely remove the > required files; (b) just create a separate test case by initializing a > fresh node for primary and standby where we only have logical slots on > standby. This will be a bit costly but probably less risky. (c) any > better ideas? > (c): Since, I think, the physical slot on the primary is not a concern for the reason mentioned above, then instead of (b): What about postponing the physical slot creation on the standby and the cascading standby node initialization after this test? That way, this test would be done without a physical slot on the standby and we could also get rid of the "Wait for the cascading standby to catchup before removing the WAL file(s)" part. Regards, -- Bertrand Drouvot PostgreSQL Contributors Team RDS Open Source Databases Amazon Web Services: https://aws.amazon.com