public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Lakhin <[email protected]>
To: Robert Haas <[email protected]>
To: Nathan Bossart <[email protected]>
Cc: Matthias van de Meent <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: cleanup patches for incremental backup
Date: Sat, 27 Jan 2024 10:00:01 +0300
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+TgmoY=isnbxFcoCT9_7X8aEGJ=6jUEB_2N+kpKROerasmhUw@mail.gmail.com>
References: <CAEze2WjhdVCqEe_qqEok3NA6DwUdOGSBjAxzmYdAqiaaH1uRcg@mail.gmail.com>
<CA+TgmoaQHtGNFczJzSO5sMobUpuikSHphtFPZpdLmjzwdmM1DQ@mail.gmail.com>
<20240124170846.GA2643050@nathanxps13>
<CA+TgmoZusu5g3rM1k=UB29Sf53c1OKjm1uFw9uo-sSXBLFZJiQ@mail.gmail.com>
<20240124180515.GA2709722@nathanxps13>
<CA+TgmobWwfMpog9Yz=krBT1=sobGzWNxuEiCXg4Hh92fNOMHJw@mail.gmail.com>
<20240124193922.GA2711912@nathanxps13>
<CA+TgmoaC39=6Mc=b4zGVn86r7-1YPZtYQf=fVPaKdEXrA2i0dA@mail.gmail.com>
<20240125160850.GA2729380@nathanxps13>
<CA+TgmoZLXsorAX2XNxC1+zKFSagCZUk4Qiq49+WxTk8oePvWCQ@mail.gmail.com>
<20240126173904.GA2765759@nathanxps13>
<CA+TgmoY=isnbxFcoCT9_7X8aEGJ=6jUEB_2N+kpKROerasmhUw@mail.gmail.com>
Hello Robert,
26.01.2024 21:37, Robert Haas wrote:
> On Fri, Jan 26, 2024 at 12:39 PM Nathan Bossart
> <[email protected]> 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
view thread (33+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: cleanup patches for incremental backup
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox