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.