Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rhLyL-00B1Eb-Lp for pgsql-bugs@arkaria.postgresql.org; Tue, 05 Mar 2024 04:00:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rhLyJ-00DCDf-8T for pgsql-bugs@arkaria.postgresql.org; Tue, 05 Mar 2024 04:00:07 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rhLyI-00DCDX-QN for pgsql-bugs@lists.postgresql.org; Tue, 05 Mar 2024 04:00:07 +0000 Received: from mail-lf1-x134.google.com ([2a00:1450:4864:20::134]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rhLyF-002u7O-Ch for pgsql-bugs@lists.postgresql.org; Tue, 05 Mar 2024 04:00:05 +0000 Received: by mail-lf1-x134.google.com with SMTP id 2adb3069b0e04-513382f40e9so3442536e87.2 for ; Mon, 04 Mar 2024 20:00:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1709611203; x=1710216003; darn=lists.postgresql.org; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=cw5aAOX87FFjBlNusFlxa8pOz8owhm5uxEh/BIDI5tw=; b=AW+cp1pIoEjCJYrBB4kgTtP5rQHQ5k+jm4JbVYQAzRR0L6YfaI4Qwi39+hDnA5lLSU w9fpCmZ10t+0ebuMsAXs3SNUClfKd1zeOyyyxuVkWyeBZaaJ94uLRoGvk8AbhIT75tHa WdzyfkEl6BG35roN3i3M8x+AyrwHcL3zS4gtS3ig6xbemdP7WQ7TiOGj5XW8xdgdCaiY t5ryWk4wQnwk1ABDiv4IoHHqkCqfnj8grtV2dKMx+6Gsk+wmbWGBvjc5RxYBCfTh+AwI ukLTo3rHFkKYdkyYq7fn8vFs/kV8Rt6rq1zm9dgadCXvVjAHhF+AFEVM2/GnFFgHv38W pNfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1709611203; x=1710216003; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=cw5aAOX87FFjBlNusFlxa8pOz8owhm5uxEh/BIDI5tw=; b=lWBc2y/QKLtmLxcHm3GRFnOKtNkhW4fy7wy10Hqc40GfO9ri+JZjf+Ufbvt3qSQkT7 UeVv2fPzzHEu8Ux2Wkh2AisCdtepYDJ/ayVvc48SFfk5WzmL26yKMM7rcqRhXvjJJpY8 TDD5g7sxRzhA2Z3SwwhLRf1kt+0jaGOdLxRhRCDt6TMKdNFz5e35VctKfzuUq8t6poVF 337eFTn07hsuS1hMgQnSEGLYx72SLX4HYQs8/TB13YkbYChakI54ffcL7j/EiI5s3lPs +bxH7urzlYaVTc0IXsNC/LUfRgxT6/H1nG4dDdDphZmG2Ao+gHWpwJ3fcesdQr67fGn9 2z7g== X-Gm-Message-State: AOJu0Yw+EkHElGv3YkHopuciu/AT2PPPON+JJJ2Tar1cjtOdg2pOMOKP JyrVu9Ar73msQcIafjmtjKx7TAsAxU7r0q8DHfKDIRp759uL3dIl X-Google-Smtp-Source: AGHT+IH2rKLLD8vyc2nhDVrK0OcsnXiHPa4mczbESmuY7lXhr2BWeUn+SNBO+paTLLVH3wq+5+l1Mw== X-Received: by 2002:a05:6512:280f:b0:513:134f:8250 with SMTP id cf15-20020a056512280f00b00513134f8250mr436867lfb.55.1709611202591; Mon, 04 Mar 2024 20:00:02 -0800 (PST) Received: from [1.0.0.7] ([178.155.30.186]) by smtp.gmail.com with ESMTPSA id l27-20020ac24a9b000000b005132f8547cdsm1642503lfp.19.2024.03.04.20.00.01 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Mar 2024 20:00:02 -0800 (PST) Content-Type: multipart/alternative; boundary="------------1mduwvkSZal6XL8kB5OfSkmL" Message-ID: Date: Tue, 5 Mar 2024 07: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: "Hayato Kuroda (Fujitsu)" , ocean_li_996 Cc: "pgsql-bugs@lists.postgresql.org" , Amit Kapila References: <18369-ad61699bf91c5bc0@postgresql.org> <6d0e80d6.c1fc.18deeb8120a.Coremail.ocean_li_996@163.com> <3d696d51.cfa6.18deeccd483.Coremail.ocean_li_996@163.com> <3900f282.3f49.18df2ae796a.Coremail.ocean_li_996@163.com> From: Alexander Lakhin In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk This is a multi-part message in MIME format. --------------1mduwvkSZal6XL8kB5OfSkmL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Kuroda-san, 04.03.2024 15:52, Hayato Kuroda (Fujitsu) wrote: > > Dear Alexander, > > I also ran your script after applying patches on REL_14_STABLE, but I got another failure. > > I have not analyzed yet so I share the result as-is. > > Was I missing something? > > > ``` > > #0 0x00007f4f033de387 in raise () from /lib64/libc.so.6 > > #1 0x00007f4f033dfa78 in abort () from /lib64/libc.so.6 > > #2 0x0000000000b08152 in ExceptionalCondition (conditionName=0xcc8228 "prev_first_lsn < cur_txn->first_lsn", > >     errorType=0xcc8024 "FailedAssertion", fileName=0xcc8070 "reorderbuffer.c", lineNumber=916) at assert.c:69 > > #3 0x00000000008e01ad in AssertTXNLsnOrder (rb=0x19a95c0) at reorderbuffer.c:916 > > #4 0x00000000008dfae8 in ReorderBufferTXNByXid (rb=0x19a95c0, xid=1753, create=true, is_new=0x0, lsn=37430336, > >     create_as_top=true) at reorderbuffer.c:669 > > Yes, you're right. That script produces another failure as I mentioned upthread, but still in AssertTXNLsnOrder(). I had thought that the fix should cover that case too, but then I found out that the defect in question is rather new, so maybe the more focused fix is really preferable. Best regards, Alexander --------------1mduwvkSZal6XL8kB5OfSkmL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hello Kuroda-san,

04.03.2024 15:52, Hayato Kuroda (Fujitsu) wrote:

Dear Alexander,

 

I also ran your script after applying patches on REL_14_STABLE, but I got another failure.

I have not analyzed yet so I share the result as-is.

Was I missing something?


```

#0  0x00007f4f033de387 in raise () from /lib64/libc.so.6

#1  0x00007f4f033dfa78 in abort () from /lib64/libc.so.6

#2  0x0000000000b08152 in ExceptionalCondition (conditionName=0xcc8228 "prev_first_lsn < cur_txn->first_lsn",

    errorType=0xcc8024 "FailedAssertion", fileName=0xcc8070 "reorderbuffer.c", lineNumber=916) at assert.c:69

#3  0x00000000008e01ad in AssertTXNLsnOrder (rb=0x19a95c0) at reorderbuffer.c:916

#4  0x00000000008dfae8 in ReorderBufferTXNByXid (rb=0x19a95c0, xid=1753, create=true, is_new=0x0, lsn=37430336,

    create_as_top=true) at reorderbuffer.c:669



Yes, you're right. That script produces another failure as I mentioned
upthread, but still in AssertTXNLsnOrder().
I had thought that the fix should cover that case too, but then I found out
that the defect in question is rather new, so maybe the more focused fix is
really preferable.

Best regards,
Alexander
--------------1mduwvkSZal6XL8kB5OfSkmL--