public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alexander Korotkov <[email protected]>
To: Alexander Lakhin <[email protected]>
Cc: Vitaly Davydov <[email protected]>
Cc: Amit Kapila <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: [email protected]
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
Date: Sun, 15 Jun 2025 14:02:44 +0300
Message-ID: <CAPpHfdvPpg5VUTNOqfKSNx66ij3ZJNZbf4kn6SDcPkdq9FTvng@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <1d12d2-67235980-35-19a406a0@63439497>
<CAA4eK1KMaPA5jir_SFu+qr3qu55OOdFWVZpuUkqTSGZ9fyPpHA@mail.gmail.com>
<2c1d-68344100-b7-3411b8c0@256938178>
<CAA4eK1LmVoZ8jm5Jt3DERN9Z=y6L6xj5O0asw0smWw31Y8KfVw@mail.gmail.com>
<CAPpHfdtp61pSt72KxxOnnV_Oj4OTAiKYCSTek0Pm87hVDod4Bg@mail.gmail.com>
<CAA4eK1Lmd-stXWrNqX9iXugjY=ahhe7zRfyq+-vN512xvF4G2w@mail.gmail.com>
<CAPpHfdsTiYQPywr4yeqVhUtA+eFdqisqcAOiTb+kiYhi9EVEvw@mail.gmail.com>
<CAPpHfdvk-nfu5xzJyPArxWctofWPR+1L9uJ+yyWFA34n6b5rGQ@mail.gmail.com>
<CAA4eK1Ladnm40UO-YC+c7eBYqjyFQSwg0dn1w_CiaMoBTsJUDA@mail.gmail.com>
<CAPpHfduX--KKX853UwaJ8Cjo5bxbh19V_+McKQ3p9aS6b8T1Wg@mail.gmail.com>
<CAA4eK1+VbBxYY-rG4B7Jq6TsYvdjt3d2nbUrs7p9-1sP5mH+sw@mail.gmail.com>
<CAPpHfdvxqjE+RZdoOODQZAmQip6NpvSH40DuvVFWuf_00ek-yQ@mail.gmail.com>
<1d97ec-6841b600-3-b7b4780@40747246>
<CAA4eK1LvssAcp61qg957xRF0=K4xF0hfJQjQ6c9V7EGHSqraPg@mail.gmail.com>
<28c8bf-68470780-3-51b29480@89454035>
<CAPpHfdt77k3BqD=anh4b7UiRevfPOu2Hcf3rvSZXntxH+4G=Ug@mail.gmail.com>
<[email protected]>
On Sun, Jun 15, 2025 at 12:00 PM Alexander Lakhin <[email protected]> wrote:
>
> Hello Alexander,
>
> 10.06.2025 23:14, Alexander Korotkov wrote:
>
> So, my proposal is to commit the attached patchset to the HEAD, and
> commit [1] to the back branches. Any objections?
>
>
> As the buildfarm animal prion shows [1], the 046_checkpoint_logical_slot
> test fails with "-DRELCACHE_FORCE_RELEASE -DCATCACHE_FORCE_RELEASE":
> # poll_query_until timed out executing this query:
> #
> # SELECT count(*) > 0 FROM pg_stat_activity
> # WHERE backend_type = 'client backend' AND wait_event = 'logical-replication-slot-advance-segment'
> #
> # expecting this output:
> # t
> # last actual query output:
> # f
> # with stderr:
> [04:16:27] t/046_checkpoint_logical_slot.pl ......
> Dubious, test returned 29 (wstat 7424, 0x1d00)
> No subtests run
> [04:20:58] t/047_checkpoint_physical_slot.pl ..... ok 271294 ms ( 0.00 usr 0.00 sys + 0.37 cusr 0.26 csys = 0.63 CPU)
>
> I'm able to reproduce this locally as well. Though the test passes for me
> with the increased timeout, that is it's not stuck:
> PG_TEST_TIMEOUT_DEFAULT=360 PROVE_TESTS="t/046*" make -s check -C src/test/recovery/
> # +++ tap check in src/test/recovery +++
> t/046_checkpoint_logical_slot.pl .. ok
> All tests successful.
> Files=1, Tests=1, 533 wallclock secs ( 0.01 usr 0.00 sys + 4.70 cusr 9.61 csys = 14.32 CPU)
> Result: PASS
>
> Could you have a look?
>
> [1] https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=prion&dt=2025-06-14%2001%3A58%3A06
Could you, please, check this patch? On my system it makes 046 and
047 execute in 140 secs with -O0 and -DRELCACHE_FORCE_RELEASE
-DCATCACHE_FORCE_RELEASE.
------
Regards,
Alexander Korotkov
Supabase
Attachments:
[application/octet-stream] v1-0001-Fix-046_checkpoint_-logical-physical-_slot.pl-exe.patch (3.0K, ../CAPpHfdvPpg5VUTNOqfKSNx66ij3ZJNZbf4kn6SDcPkdq9FTvng@mail.gmail.com/2-v1-0001-Fix-046_checkpoint_-logical-physical-_slot.pl-exe.patch)
download | inline diff:
From db591b3c0b9ae760395f79df68ca78922108e7f4 Mon Sep 17 00:00:00 2001
From: Alexander Korotkov <[email protected]>
Date: Sun, 15 Jun 2025 13:54:09 +0300
Subject: [PATCH v1] Fix 046_checkpoint_(logical/physical)_slot.pl execution
time
Reported-by:
Bug:
Discussion:
Author:
Reviewed-by:
Tested-by:
Backpatch-through:
---
src/test/recovery/t/046_checkpoint_logical_slot.pl | 8 ++++----
src/test/recovery/t/047_checkpoint_physical_slot.pl | 8 ++++----
2 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/src/test/recovery/t/046_checkpoint_logical_slot.pl b/src/test/recovery/t/046_checkpoint_logical_slot.pl
index b4265c4a6a5..4fe928210dd 100644
--- a/src/test/recovery/t/046_checkpoint_logical_slot.pl
+++ b/src/test/recovery/t/046_checkpoint_logical_slot.pl
@@ -58,17 +58,17 @@ SELECT 1 \watch 0.1
\q
));
-# Insert 2M rows; that's about 260MB (~20 segments) worth of WAL.
+# Insert 50K rows; that's about 86MB (~5 segments) worth of WAL.
$node->safe_psql('postgres',
- q{insert into t (b) select md5(i::text) from generate_series(1,1000000) s(i)}
+ q{insert into t (b) select repeat(md5(i::text),50) from generate_series(1,50000) s(i)}
);
# Run another checkpoint to set a new restore LSN.
$node->safe_psql('postgres', q{checkpoint});
-# Another 2M rows; that's about 260MB (~20 segments) worth of WAL.
+# Another 50K rows; that's about 86MB (~5 segments) worth of WAL.
$node->safe_psql('postgres',
- q{insert into t (b) select md5(i::text) from generate_series(1,1000000) s(i)}
+ q{insert into t (b) select repeat(md5(i::text),50) from generate_series(1,50000) s(i)}
);
# Run another checkpoint, this time in the background, and make it wait
diff --git a/src/test/recovery/t/047_checkpoint_physical_slot.pl b/src/test/recovery/t/047_checkpoint_physical_slot.pl
index 454e56b9bd2..3141b256bf3 100644
--- a/src/test/recovery/t/047_checkpoint_physical_slot.pl
+++ b/src/test/recovery/t/047_checkpoint_physical_slot.pl
@@ -43,9 +43,9 @@ $node->safe_psql('postgres',
# Run checkpoint to flush current state to disk and set a baseline.
$node->safe_psql('postgres', q{checkpoint});
-# Insert 2M rows; that's about 260MB (~20 segments) worth of WAL.
+# Insert 50K rows; that's about 86MB (~5 segments) worth of WAL.
$node->safe_psql('postgres',
- q{insert into t (b) select md5(i::text) from generate_series(1,100000) s(i)}
+ q{insert into t (b) select repeat(md5(i::text),50) from generate_series(1,50000) s(i)}
);
# Advance slot to the current position, just to have everything "valid".
@@ -56,9 +56,9 @@ $node->safe_psql('postgres',
# Run another checkpoint to set a new restore LSN.
$node->safe_psql('postgres', q{checkpoint});
-# Another 2M rows; that's about 260MB (~20 segments) worth of WAL.
+# Another 50K rows; that's about 86MB (~5 segments) worth of WAL.
$node->safe_psql('postgres',
- q{insert into t (b) select md5(i::text) from generate_series(1,1000000) s(i)}
+ q{insert into t (b) select repeat(md5(i::text),50) from generate_series(1,50000) s(i)}
);
my $restart_lsn_init = $node->safe_psql('postgres',
--
2.39.5 (Apple Git-154)
view thread (73+ 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], [email protected]
Subject: Re: Slot's restart_lsn may point to removed WAL segment after hard restart unexpectedly
In-Reply-To: <CAPpHfdvPpg5VUTNOqfKSNx66ij3ZJNZbf4kn6SDcPkdq9FTvng@mail.gmail.com>
* 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