To: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Peter Geoghegan <pg@bowt.ie>
From: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Subject: nbtree: assertion failure in _bt_killitems() for posting tuple
Message-ID: <c4e38e9a-0f9c-8e53-e639-adf343f94472@postgrespro.ru>
Date: Thu, 19 Mar 2020 19:34:17 +0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.4.1
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Precedence: bulk

During tests, we catched an assertion failure in _bt_killitems() for 
posting tuple in unique index:

/* kitem must have matching offnum when heap TIDs match */
Assert(kitem->indexOffset == offnum);

https://github.com/postgres/postgres/blob/master/src/backend/access/nbtree/nbtutils.c#L1809

I struggle to understand the meaning of this assertion.
Don't we allow the chance that posting tuple moved right on the page as 
the comment says?

  * We match items by heap TID before assuming they are the right ones to
  * delete.  We cope with cases where items have moved right due to 
insertions.

It seems that this is exactly the case for this failure.
We expected to find tuple at offset 121, but instead it is at offset 
125.  (see dump details below).

Unfortunately I cannot attach test and core dump, since they rely on the 
enterprise multimaster extension code.
Here are some details from the core dump, that I find essential:

Stack is
_bt_killitems
_bt_release_current_position
_bt_release_scan_state
btrescan
index_rescan
RelationFindReplTupleByIndex

(gdb) p offnum
$3 = 125
(gdb) p *item
$4 = {ip_blkid = {bi_hi = 0, bi_lo = 2}, ip_posid = 200}
(gdb) p *kitem
$5 = {heapTid = {ip_blkid = {bi_hi = 0, bi_lo = 2}, ip_posid = 200}, 
indexOffset = 121, tupleOffset = 32639}


Unless I miss something, this assertion must be removed.

-- 
Anastasia Lubennikova
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company