From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: r.zharkov@postgrespro.ru
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andres Freund <andres@anarazel.de>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
Date: Wed, 3 Apr 2019 09:20:27 -0300
Message-ID: <20190403122027.GA17929@alvherre.pgsql> (raw)
In-Reply-To: <4f71a201d23777478ae48c548dd6f9d1@postgrespro.ru>
On 2019-Apr-03, r.zharkov@postgrespro.ru wrote:
> #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
Uhm ... this assertion failure is doesn't seem related to the other
problem you were reporting. Here, it's failing because it thinks the
tuple should be marked as only locked when the current transaction is
the only Xmax for the tuple.
/*
* As a check independent from those above, we can also avoid sleeping
* if the current transaction is the sole locker of the tuple. Note
* that the strength of the lock already held is irrelevant; this is
* not about recording the lock in Xmax (which will be done regardless
* of this optimization, below). Also, note that the cases where we
* hold a lock stronger than we are requesting are already handled
* above by not doing anything.
*
* Note we only deal with the non-multixact case here; MultiXactIdWait
* is well equipped to deal with this situation on its own.
*/
if (require_sleep && !(infomask & HEAP_XMAX_IS_MULTI) &&
TransactionIdIsCurrentTransactionId(xwait))
{
/* ... but if the xmax changed in the meantime, start over */
LockBuffer(*buffer, BUFFER_LOCK_EXCLUSIVE);
if (xmax_infomask_changed(tuple->t_data->t_infomask, infomask) ||
!TransactionIdEquals(HeapTupleHeaderGetRawXmax(tuple->t_data),
xwait))
goto l3;
Assert(HEAP_XMAX_IS_LOCKED_ONLY(tuple->t_data->t_infomask)); // <--- failed assertion
require_sleep = false;
}
I'm not quite sure what's up with that.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: alvherre@2ndquadrant.com, r.zharkov@postgrespro.ru, tgl@sss.pgh.pa.us, andres@anarazel.de, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
In-Reply-To: <20190403122027.GA17929@alvherre.pgsql>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox