Date: Wed, 3 Apr 2019 09:20:27 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: r.zharkov@postgrespro.ru
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
	pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was
 already committed
Message-ID: <20190403122027.GA17929@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4f71a201d23777478ae48c548dd6f9d1@postgrespro.ru>
User-Agent: Mutt/1.9.4 (2018-02-28)
Precedence: bulk

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