Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()

From: ocean_li_996 <ocean_li_996(at)163(dot)com>
To: "Alexander Lakhin" <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org, "Amit Kapila" <amit(dot)kapila16(at)gmail(dot)com>
Subject: Re:Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()
Date: 2024-02-29 16:44:29
Message-ID: 6444e39.131bc.18df5c0cae3.Coremail.ocean_li_996@163.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

At 2024-02-29 18:00:00, "Alexander Lakhin" <exclusion(at)gmail(dot)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.

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message PetSerAl 2024-02-29 18:15:56 Record returning function accept not matched columns declaration
Previous Message Tom Lane 2024-02-29 15:20:24 Re: BUG #18372: Timezone documentation and use of TZ and PGTZ environment variables missing since version 7.4