Content-Type: multipart/alternative;
 boundary="------------yjFCxMiTFyqvPb9pnBpYUbyw"
Message-ID: <e8236368-6b2b-6b76-a0c1-a064523a8f2c@gmail.com>
Date: Thu, 29 Feb 2024 13:00:00 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.2
Subject: Re: BUG #18369: logical decoding core on AssertTXNLsnOrder()
Content-Language: en-US
To: ocean_li_996 <ocean_li_996@163.com>
Cc: pgsql-bugs@lists.postgresql.org, Amit Kapila <amit.kapila16@gmail.com>
References: <18369-ad61699bf91c5bc0@postgresql.org>
 <6d0e80d6.c1fc.18deeb8120a.Coremail.ocean_li_996@163.com>
 <3d696d51.cfa6.18deeccd483.Coremail.ocean_li_996@163.com>
 <c79e5171-cce8-9bd7-9578-5b3a440361f9@gmail.com>
 <3900f282.3f49.18df2ae796a.Coremail.ocean_li_996@163.com>
From: Alexander Lakhin <exclusion@gmail.com>
In-Reply-To: <3900f282.3f49.18df2ae796a.Coremail.ocean_li_996@163.com>
Archived-At: 
 <https://www.postgresql.org/message-id/e8236368-6b2b-6b76-a0c1-a064523a8f2c%40gmail.com>
Precedence: bulk

This is a multi-part message in MIME format.
--------------yjFCxMiTFyqvPb9pnBpYUbyw
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Haiyang,

29.02.2024 05:25, ocean_li_996 wrote:
> > With your patch applied (on REL_14_STABLE) I still get:
> > TRAP: FailedAssertion("builder->next_phase_at == InvalidTransactionId", File: "snapbuild.c", Line: 1623, PID: 92772)
> >
> > when running make -s installcheck-force -C contrib/test_decoding...
> > as specified in that message.
> > (You might need to disable REGRESS tests in the Makefile to reach
> > isolation tests.)
> I'm not sure if I fully get your mind. I disabled the REGRESS tests in the test_decoding/Makefile and then manually 
> run the command "make -s installcheck-force -C contrib/test_decoding" a few times. I didn't encounter the issue you 
> mentioned. Is this problem consistently reproducible in your environment? BTW, the  issue mentioned in [1] is more 
> similar to your problem. And the patch was not applied to v14.  Maybe it is another issue.
>

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

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).

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.

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

Best regards,
Alexander
--------------yjFCxMiTFyqvPb9pnBpYUbyw
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Hi Haiyang,<br>
      <br>
      29.02.2024 05:25, ocean_li_996 wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:3900f282.3f49.18df2ae796a.Coremail.ocean_li_996@163.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div
        style="line-height:1.7;color:#000000;font-size:14px;font-family:Arial">&gt;
        With your patch applied (on REL_14_STABLE) I still get:<br>
        <div>&gt; TRAP: FailedAssertion("builder-&gt;next_phase_at ==
          InvalidTransactionId", File: "snapbuild.c", Line: 1623, PID:
          92772)<br>
          &gt;<br>
          &gt; when running make -s installcheck-force -C
          contrib/test_decoding...<br>
          &gt; as specified in that message.<br>
          &gt; (You might need to disable REGRESS tests in the Makefile
          to reach<br>
          &gt; isolation tests.)</div>
        <div>
          <div>I'm not sure if I fully get your mind. I disabled the
            REGRESS tests in the test_decoding/Makefile and then
            manually run the command "make -s installcheck-force -C
            contrib/test_decoding" a few times. I didn't encounter the
            issue you mentioned. Is this problem consistently
            reproducible in your environment? BTW, the  issue mentioned
            in [1] is more similar to your problem. And the patch was
            not applied to v14.  Maybe it is another issue.</div>
          <br>
        </div>
      </div>
    </blockquote>
    <br>
    You can try the following script (assuming a server with the
    test_decoding<br>
    module installed is running):<br>
    rm -rf contrib/test_decoding_*<br>
    numclients=5<br>
    for ((c=1;c&lt;=numclients;c++)); do<br>
       cp -r contrib/test_decoding contrib/test_decoding_$c<br>
       sed "s/REGRESS = /# REGRESS =/" -i
    contrib/test_decoding_$c/Makefile<br>
       sed "s/isolation_slot/isolation_slot_$c/" -i
    contrib/test_decoding_$c/specs/catalog_change_snapshot.spec # Use
    independent slots<br>
       sed "$(printf '$p; %.0s' `seq 50`)" -i
    contrib/test_decoding_$c/specs/catalog_change_snapshot.spec # Repeat
    the last permutation 50 times<br>
    done<br>
    for ((c=1;c&lt;=numclients;c++)); do<br>
       EXTRA_REGRESS_OPTS="--dbname=regress_$c" make -s
    installcheck-force -C contrib/test_decoding_$c USE_MODULE_DB=1 
    &gt;"installcheck-$c.log" 2&gt;&amp;1 &amp;<br>
    done<br>
    wait<br>
    <br>
    Though that's really not directly related to the current issue
    (sorry for<br>
    the wrong direction, my point was that there are still living bugs
    in this<br>
    area).<br>
    <br>
    I've found that your added test case fails on REL_15_STABLE starting
    from<br>
    b793a416b (6b77048e5 on REL_14_STABLE), so it looks like this is a
    new<br>
    defect introduced in REL_14_STABLE, REL_15_STABLE recently with the
    fix for<br>
    bug #18280.<br>
    <br>
    As to REL_13_STABLE/REL_12_STABLE the failure reproduced starting
    from<br>
    commits 38dbaaf27/02600886c, a result of the aforementioned
    discussion:<br>
<a class="moz-txt-link-freetext" href="https://www.postgresql.org/message-id/CAA4eK1Lx%3Dg09z2k9Teq9ca1eRzfpfxJwFdjyHNwgEKv69KWhrQ%40mail.gmail.com">https://www.postgresql.org/message-id/CAA4eK1Lx%3Dg09z2k9Teq9ca1eRzfpfxJwFdjyHNwgEKv69KWhrQ%40mail.gmail.com</a><br>
    <br>
    Best regards,<br>
    Alexander<br>
  </body>
</html>

--------------yjFCxMiTFyqvPb9pnBpYUbyw--