nbtree: assertion failure in _bt_killitems() for posting tuple

From: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Peter Geoghegan <pg(at)bowt(dot)ie>
Subject: nbtree: assertion failure in _bt_killitems() for posting tuple
Date: 2020-03-19 16:34:17
Message-ID: c4e38e9a-0f9c-8e53-e639-adf343f94472@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabrízio de Royes Mello 2020-03-19 16:37:17 Re: backend type in log_line_prefix?
Previous Message Pavel Stehule 2020-03-19 16:09:13 Re: proposal: new polymorphic types - commontype and commontypearray