Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed - Mailing list pgsql-bugs

From r.zharkov@postgrespro.ru
Subject Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed
Date
Msg-id 4f71a201d23777478ae48c548dd6f9d1@postgrespro.ru
Whole thread Raw
In response to Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-bugs
On 2019-04-03 00:13, Tom Lane wrote:
> r.zharkov@postgrespro.ru writes:
>> I made the new core file:
> 
> Thanks, but this isn't much help --- it just shows what we already
> know, ie the "cannot abort transaction" error occurs after some other
> error was thrown.
> 
> What would be more helpful would be to adjust the places that
> can throw the "unexpected table_lock_tuple status" error text to be
> PANIC rather than ERROR, so that the core dump would show a stack
> trace showing how we got to whichever of those places this is.
> Or, run the test with a higher log verbosity, so that you can find
> out which of those places is throwing the error to begin with;
> then just PANIC-ize that one.
> 
> FWIW, I see six potential candidates, not two:
> 
> pgsql/src/backend/commands/trigger.c: 3380:                 elog(ERROR,
> "unexpected table_lock_tuple status: %u", test);
> pgsql/src/backend/executor/nodeLockRows.c: 232:                 elog(ERROR,
> "unexpected table_lock_tuple status: %u",
> pgsql/src/backend/executor/nodeModifyTable.c: 881:                             elog(ERROR,
> "unexpected table_lock_tuple status: %u",
> pgsql/src/backend/executor/nodeModifyTable.c: 1384:                             elog(ERROR,
> "unexpected table_lock_tuple status: %u",
> pgsql/src/backend/executor/execReplication.c: 211:                 elog(ERROR,
> "unexpected table_lock_tuple status: %u", res);
> pgsql/src/backend/executor/execReplication.c: 375:                 elog(ERROR,
> "unexpected table_lock_tuple status: %u", res);
> 
> 
>             regards, tom lane

Hello,
I have made the new core dump. Here are the results:
PostgreSQL 12devel-master/bb76134

Log:
TRAP: FailedAssertion("!((((tuple->t_data->t_infomask) & 0x0080) || 
(((tuple->t_data->t_infomask) & (0x1000 | ((0x0040 | 0x0010) | 0x0040 | 
0x0010))) == 0x0040)))", File: "heapam.c", Line:
2019-04-03 15:13:36.668 +07 [23163] LOG:  server process (PID 27904) was 
terminated by signal 6: Aborted
2019-04-03 15:13:36.668 +07 [23163] DETAIL:  Failed process was running: 
UPDATE pgbench_accounts SET abalance = 1 WHERE aid = 2;
2019-04-03 15:13:36.668 +07 [23163] LOG:  terminating any other active 
server processes
2019-04-03 15:13:36.669 +07 [27907] WARNING:  terminating connection 
because of crash of another server process

Backtrace:
[New LWP 27904]
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `postgres: zharkov test 127.0.0.1(44582) UPDATE    
     '.
Program terminated with signal SIGABRT, Aborted.
#0  0x00007f5e0dc7b428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
54      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  0x00007f5e0dc7b428 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:54
#1  0x00007f5e0dc7d02a in __GI_abort () at abort.c:89
#2  0x0000000000a9b7ce in ExceptionalCondition (
     conditionName=0xb3de08 "!((((tuple->t_data->t_infomask) & 0x0080) || 
(((tuple->t_data->t_infomask) & (0x1000 | ((0x0040 | 0x0010) | 0x0040 | 
0x0010))) == 0x0040)))",
     errorType=0xb39a69 "FailedAssertion", fileName=0xb39ae8 "heapam.c", 
lineNumber=4286) at assert.c:54
#3  0x00000000004ea024 in heap_lock_tuple (relation=0x7f5e0f252d80, 
tuple=0x30f4dd0, cid=0, mode=LockTupleNoKeyExclusive, 
wait_policy=LockWaitBlock, follow_updates=false,
     buffer=0x7ffed968cbb4, tmfd=0x7ffed968cd80) at heapam.c:4286
#4  0x00000000004f5903 in heapam_tuple_lock (relation=0x7f5e0f252d80, 
tid=0x7ffed968cdf0, snapshot=0x303cef0, slot=0x30f4d80, cid=0, 
mode=LockTupleNoKeyExclusive,
     wait_policy=LockWaitBlock, flags=2 '\002', tmfd=0x7ffed968cd80) at 
heapam_handler.c:352
#5  0x000000000074055a in table_lock_tuple (rel=0x7f5e0f252d80, 
tid=0x7ffed968cdf0, snapshot=0x303cef0, slot=0x30f4d80, cid=0, 
mode=LockTupleNoKeyExclusive, wait_policy=LockWaitBlock,
     flags=2 '\002', tmfd=0x7ffed968cd80) at 
../../../src/include/access/tableam.h:993
#6  0x00000000007421cc in ExecUpdate (mtstate=0x30eb780, 
tupleid=0x7ffed968cdf0, oldtuple=0x0, slot=0x30ed1c8, 
planSlot=0x30ed050, epqstate=0x30eb878, estate=0x30eb3d8, 
canSetTag=true)
     at nodeModifyTable.c:1242
#7  0x0000000000743756 in ExecModifyTable (pstate=0x30eb780) at 
nodeModifyTable.c:2070
#8  0x0000000000712671 in ExecProcNodeFirst (node=0x30eb780) at 
execProcnode.c:445
#9  0x000000000070748c in ExecProcNode (node=0x30eb780) at 
../../../src/include/executor/executor.h:239
#10 0x0000000000709d11 in ExecutePlan (estate=0x30eb3d8, 
planstate=0x30eb780, use_parallel_mode=false, operation=CMD_UPDATE, 
sendTuples=false, numberTuples=0,
     direction=ForwardScanDirection, dest=0x30ee508, execute_once=true) 
at execMain.c:1643
#11 0x0000000000707ac9 in standard_ExecutorRun (queryDesc=0x303faf8, 
direction=ForwardScanDirection, count=0, execute_once=true) at 
execMain.c:362
#12 0x0000000000707905 in ExecutorRun (queryDesc=0x303faf8, 
direction=ForwardScanDirection, count=0, execute_once=true) at 
execMain.c:306
#13 0x0000000000915950 in ProcessQuery (plan=0x30df120, 
sourceText=0x30161d8 "UPDATE pgbench_accounts SET abalance = 1 WHERE aid 
= 2;", params=0x0, queryEnv=0x0, dest=0x30ee508,
     completionTag=0x7ffed968d270 "") at pquery.c:161
#14 0x000000000091739c in PortalRunMulti (portal=0x3098078, 
isTopLevel=true, setHoldSnapshot=false, dest=0x30ee508, 
altdest=0x30ee508, completionTag=0x7ffed968d270 "") at pquery.c:1283
#15 0x00000000009168e8 in PortalRun (portal=0x3098078, 
count=9223372036854775807, isTopLevel=true, run_once=true, 
dest=0x30ee508, altdest=0x30ee508, completionTag=0x7ffed968d270 "")
     at pquery.c:796
#16 0x000000000091027a in exec_simple_query (query_string=0x30161d8 
"UPDATE pgbench_accounts SET abalance = 1 WHERE aid = 2;") at 
postgres.c:1215
#17 0x00000000009148ff in PostgresMain (argc=1, argv=0x3042980, 
dbname=0x3042960 "test", username=0x3012d98 "zharkov") at 
postgres.c:4247
#18 0x000000000086406c in BackendRun (port=0x303b030) at 
postmaster.c:4399
#19 0x00000000008637cd in BackendStartup (port=0x303b030) at 
postmaster.c:4090
#20 0x000000000085facf in ServerLoop () at postmaster.c:1703
#21 0x000000000085f2dd in PostmasterMain (argc=3, argv=0x3010d00) at 
postmaster.c:1376
#22 0x000000000077aeba in main (argc=3, argv=0x3010d00) at main.c:228


The changes I made:
diff --git a/src/backend/commands/trigger.c 
b/src/backend/commands/trigger.c
index e03ffdd..ab3bace 100644
--- a/src/backend/commands/trigger.c
+++ b/src/backend/commands/trigger.c
@@ -3358,7 +3358,7 @@ GetTupleForTrigger(EState *estate,
                                         ereport(ERROR,
                                                         
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
                                                          errmsg("could 
not serialize access due to concurrent update")));
-                               elog(ERROR, "unexpected table_lock_tuple 
status: %u", test);
+                               elog(PANIC, "unexpected table_lock_tuple 
status: %u", test);
                                 break;

                         case TM_Deleted:
diff --git a/src/backend/executor/execReplication.c 
b/src/backend/executor/execReplication.c
index d8b48c6..d06cbe0 100644
--- a/src/backend/executor/execReplication.c
+++ b/src/backend/executor/execReplication.c
@@ -207,7 +207,7 @@ retry:
                                 elog(ERROR, "attempted to lock invisible 
tuple");
                                 break;
                         default:
-                               elog(ERROR, "unexpected table_lock_tuple 
status: %u", res);
+                               elog(PANIC, "unexpected table_lock_tuple 
status: %u", res);
                                 break;
                 }
         }
@@ -371,7 +371,7 @@ retry:
                                 elog(ERROR, "attempted to lock invisible 
tuple");
                                 break;
                         default:
-                               elog(ERROR, "unexpected table_lock_tuple 
status: %u", res);
+                               elog(PANIC, "unexpected table_lock_tuple
status: %u", res);
                                 break;
                 }
         }
diff --git a/src/backend/executor/nodeLockRows.c 
b/src/backend/executor/nodeLockRows.c
index 7674ac8..c7a261c 100644
--- a/src/backend/executor/nodeLockRows.c
+++ b/src/backend/executor/nodeLockRows.c
@@ -229,7 +229,7 @@ lnext:
                                         ereport(ERROR,
                                                         
(errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
                                                          errmsg("could 
not serialize access due to concurrent update")));
-                               elog(ERROR, "unexpected table_lock_tuple 
status: %u",
+                               elog(PANIC, "unexpected table_lock_tuple 
status: %u",
                                          test);
                                 break;

diff --git a/src/backend/executor/nodeModifyTable.c 
b/src/backend/executor/nodeModifyTable.c
index 7be0e77..b15b7a0 100644
--- a/src/backend/executor/nodeModifyTable.c
+++ b/src/backend/executor/nodeModifyTable.c
@@ -780,7 +780,7 @@ ldelete:;
                                                          * locking the 
latest version via
                                                          * 
TUPLE_LOCK_FLAG_FIND_LAST_VERSION.
                                                          */
-                                                       elog(ERROR, 
"unexpected table_lock_tuple status: %u",
+                                                       elog(PANIC, 
"unexpected table_lock_tuple status: %u",
                                                                  
result);
                                                         return NULL;
                                         }
@@ -1269,7 +1269,7 @@ lreplace:;

                                                 default:
                                                         /* see 
table_lock_tuple call in ExecDelete() */
-                                                       elog(ERROR, 
"unexpected table_lock_tuple status: %u",
+                                                       elog(PANIC, 
"unexpected table_lock_tuple status: %u",
                                                                  
result);
                                                         return NULL;
                                         }


regards,

Roman Zharkov



pgsql-bugs by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Re: BUG #15731: CVE-2019-9193
Next
From: r.zharkov@postgrespro.ru
Date:
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed