Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder() - Mailing list pgsql-bugs

From ocean_li_996
Subject Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()
Date
Msg-id 6444e39.131bc.18df5c0cae3.Coremail.ocean_li_996@163.com
Whole thread Raw
In response to Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()  (Alexander Lakhin <exclusion@gmail.com>)
List 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:
Indeed.

Back to the issue in this thread, are there any suggestions or discussion on the fix patch? 

Best Regards
Haiyang Li.

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #18372: Timezone documentation and use of TZ and PGTZ environment variables missing since version 7.4
Next
From: PetSerAl
Date:
Subject: Record returning function accept not matched columns declaration