Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rTcfn-004lUJ-5w for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jan 2024 07:00:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rTcfk-004zwP-U6 for pgsql-hackers@arkaria.postgresql.org; Sat, 27 Jan 2024 07:00:12 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rTcfk-004zwH-Go for pgsql-hackers@lists.postgresql.org; Sat, 27 Jan 2024 07:00:12 +0000 Received: from mail-lj1-x234.google.com ([2a00:1450:4864:20::234]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rTcfd-003wwW-F0 for pgsql-hackers@lists.postgresql.org; Sat, 27 Jan 2024 07:00:11 +0000 Received: by mail-lj1-x234.google.com with SMTP id 38308e7fff4ca-2cf3ea86423so11590811fa.1 for ; Fri, 26 Jan 2024 23:00:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706338804; x=1706943604; darn=lists.postgresql.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=F8MbI6glM7AnAQjNEAW+i2aIKArsx+0WcOAhZbmXW/c=; b=ELANTRFLsysqgXy12fAiSl8EmMwIzj/7FKU2jHUqRC9Xah+xrHW1Tjd9FrRCkZXSaY nW5m5gn1kNa65EpTL2vjfi65naIvcWc9okgVOcVzhtiFXi/9Hpl21HUTQ/sWtkAm7u1j 1iAw1BiAI0YRVgwih/5k5vg8PyzyiuBXAyzHO9exr0GpZau1g/RkNTe63Q4d/9oV2G8/ xS9Bm/B7gxKnXnCd44mjkEsQdb0ztspmOmNrsxpLzWBaUz5KjWJUonqQFa1MPAuS6Xnk 1MqAHjT5O7ywQcYpCD52TED+swhX+dy7bbe4sOb3Y5FzGfCWiQJzfIP8QHrD4p8m+sxX HcVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706338804; x=1706943604; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=F8MbI6glM7AnAQjNEAW+i2aIKArsx+0WcOAhZbmXW/c=; b=mg6TwOSZRmdEvEI9ihEXBq1L+TdpCOBH0U1YPWr5C6xpthDP/knw8pHiPW6vNJAtIh MOeQ8sOxEC4wCpqXJ/oQNzmkfybuB1t6rJthIF0RUgsYg5SK3W8+LewEvv2RiPjbLc0l tdqDScR7hpIQt+WNnGHrd7phxay61aamih1K+RgQBwRM04hiZ39qUkGqe4nf+LP7AURP /rX/fI0eSQKFTVH1liUzOWFs5Ylnk4BcrVo19PWYL++KjbkM6sWA9aLLSu2niRYto08U 1k5ScISPYK084jSMlYnZTkVoEKykz1ZfnfqlGKs1G52LHtSqMfbyJ0XHGIy0PHL0CPn2 pXlA== X-Gm-Message-State: AOJu0YyzT/yW03gPsf6w+ZW54er9xvR3z+F4lMEG+zDQyY+PeNBdM7cy n+AWKYj3CkB9ubco7ejmrBFzaEuWszimv3Beez7qe4qth3A+xXG6 X-Google-Smtp-Source: AGHT+IG/UP4/iJwGrSGvVFg0lokTOdgs4XnGZnEDsbyr+siDZ7GknOGnsqGQMHBU1uts42kIf00ctw== X-Received: by 2002:a05:651c:1024:b0:2cf:20f5:efdb with SMTP id w4-20020a05651c102400b002cf20f5efdbmr632345ljm.38.1706338803944; Fri, 26 Jan 2024 23:00:03 -0800 (PST) Received: from [1.0.0.7] ([91.185.77.50]) by smtp.gmail.com with ESMTPSA id z13-20020a2e9b8d000000b002cd52a4a145sm390171lji.18.2024.01.26.23.00.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 26 Jan 2024 23:00:03 -0800 (PST) Content-Type: multipart/alternative; boundary="------------huAI8OHQHB9XvlPOskhObbNp" Message-ID: <7ebe70a0-6b4b-c8f9-eeca-2036e3f20ce9@gmail.com> Date: Sat, 27 Jan 2024 10:00:01 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: cleanup patches for incremental backup Content-Language: en-US To: Robert Haas , Nathan Bossart Cc: Matthias van de Meent , PostgreSQL Hackers References: <20240124170846.GA2643050@nathanxps13> <20240124180515.GA2709722@nathanxps13> <20240124193922.GA2711912@nathanxps13> <20240125160850.GA2729380@nathanxps13> <20240126173904.GA2765759@nathanxps13> From: Alexander Lakhin In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------huAI8OHQHB9XvlPOskhObbNp Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Robert, 26.01.2024 21:37, Robert Haas wrote: > On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart > wrote: >> On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote: >>> Here is v2 with that addition. >> Looks reasonable. > Thanks for the report & review. I have committed that version. While trying to reproduce the 002_blocks test failure, I've encountered another anomaly (or two): make -s check -C src/bin/pg_walsummary/ PROVE_TESTS="t/002*" PROVE_FLAGS="--timer" # +++ tap check in src/bin/pg_walsummary +++ [05:40:38] t/002_blocks.pl .. # poll_query_until timed out executing this query: # SELECT EXISTS ( #     SELECT * from pg_available_wal_summaries() #     WHERE tli = 0 AND end_lsn > '0/0' # ) # # expecting this output: # t # last actual query output: # f # with stderr: [05:40:38] t/002_blocks.pl .. ok   266739 ms ( 0.00 usr  0.01 sys + 17.51 cusr 26.79 csys = 44.31 CPU) [05:45:05] All tests successful. Files=1, Tests=3, 267 wallclock secs ( 0.02 usr  0.02 sys + 17.51 cusr 26.79 csys = 44.34 CPU) Result: PASS It looks like the test may call pg_get_wal_summarizer_state() when WalSummarizerCtl->initialized is false yet, i. e. before the first GetOldestUnsummarizedLSN() call. I could reproduce the issue easily (within 10 test runs) with pg_usleep(100000L); added inside WalSummarizerMain() just below: sigprocmask(SIG_SETMASK, &UnBlockSig, NULL); But the fact that the test passes regardless of the timeout, make me wonder, whether any test should fail when such timeout occurs? Best regards, Alexander --------------huAI8OHQHB9XvlPOskhObbNp Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello Robert,

26.01.2024 21:37, Robert Haas wrote:
On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart
<nathandbossart@gmail.com> wrote:

On Fri, Jan 26, 2024 at 11:04:37AM -0500, Robert Haas wrote:

Here is v2 with that addition.

Looks reasonable.

Thanks for the report & review. I have committed that version.

While trying to reproduce the 002_blocks test failure, I've encountered
another anomaly (or two):
make -s check -C src/bin/pg_walsummary/ PROVE_TESTS="t/002*" PROVE_FLAGS="--timer"
# +++ tap check in src/bin/pg_walsummary +++
[05:40:38] t/002_blocks.pl .. # poll_query_until timed out executing this query:
# SELECT EXISTS (
#     SELECT * from pg_available_wal_summaries()
#     WHERE tli = 0 AND end_lsn > '0/0'
# )
#
# expecting this output:
# t
# last actual query output:
# f
# with stderr:
[05:40:38] t/002_blocks.pl .. ok   266739 ms ( 0.00 usr  0.01 sys + 17.51 cusr 26.79 csys = 44.31 CPU)
[05:45:05]
All tests successful.
Files=1, Tests=3, 267 wallclock secs ( 0.02 usr  0.02 sys + 17.51 cusr 26.79 csys = 44.34 CPU)
Result: PASS

It looks like the test may call pg_get_wal_summarizer_state() when
WalSummarizerCtl->initialized is false yet, i. e. before the first
GetOldestUnsummarizedLSN() call.
I could reproduce the issue easily (within 10 test runs) with
pg_usleep(100000L);
added inside WalSummarizerMain() just below:
sigprocmask(SIG_SETMASK, &UnBlockSig, NULL);

But the fact that the test passes regardless of the timeout, make me
wonder, whether any test should fail when such timeout occurs?

Best regards,
Alexander
 --------------huAI8OHQHB9XvlPOskhObbNp--