Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()
ocean_li_996 <ocean_li_996@163.com>
From: ocean_li_996 <ocean_li_996@163.com>
To: "Alexander Lakhin" <exclusion@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org, "Amit Kapila" <amit.kapila16@gmail.com>
Date: 2024-02-29T16:44:29Z
Lists: pgsql-bugs
At 2024-02-29 18:00:00, "Alexander Lakhin" <exclusion@gmail.com> wrote: > You can try the following script (assuming a server with the test_decoding > module installed is running): > rm -rf contrib/test_decoding_* > numclients=5 > for ((c=1;c<=numclients;c++)); do > cp -r contrib/test_decoding contrib/test_decoding_$c > sed "s/REGRESS = /# REGRESS =/" -i contrib/test_decoding_$c/Makefile > sed "s/isolation_slot/isolation_slot_$c/" -i contrib/test_decoding_$c/specs/catalog_change_snapshot.spec # Use independent slots > sed "$(printf '$p; %.0s' `seq 50`)" -i contrib/test_decoding_$c/specs/catalog_change_snapshot.spec # Repeat the last permutation 50 times > done > for ((c=1;c<=numclients;c++)); do > EXTRA_REGRESS_OPTS="--dbname=regress_$c" make -s installcheck-force -C contrib/test_decoding_$c USE_MODULE_DB=1 >"installcheck-$c.log" 2>&1 & > done > wait Thanks! Before and after applying the changes on REL_14_STABLE, I executed the script (with numclients = 50) four times, respectively. Unfortunately, I wasn't able to replicate the issue you mentioned. > Though that's really not directly related to the current issue (sorry for > the wrong direction, my point was that there are still living bugs in this > area). Got it! I concur with your statement. OTOH, there is no evidence to indicate that the issue is a result of v1-0002-Fix-Coredump-On-AssertTXNLsnOrder.patch. > I've found that your added test case fails on REL_15_STABLE starting from > b793a416b (6b77048e5 on REL_14_STABLE), so it looks like this is a new > defect introduced in REL_14_STABLE, REL_15_STABLE recently with the fix for > bug #18280. Oops, I forgot to mention this information in the email. Indeed, the test I provided couldn't reproduce the issue before fixing bug #18280 While I haven't tested it, I belive that we can get another reproducing test with a little more complexity (such as needing two transactions in sequence). > As to REL_13_STABLE/REL_12_STABLE the failure reproduced starting from > commits 38dbaaf27/02600886c, a result of the aforementioned discussion: > https://www.postgresql.org/message-id/CAA4eK1Lx%3Dg09z2k9Teq9ca1eRzfpfxJwFdjyHNwgEKv69KWhrQ%40mail.gmail.com Indeed. Back to the issue in this thread, are there any suggestions or discussion on the fix patch? Best Regards Haiyang Li.