Re: nbtree: assertion failure in _bt_killitems() for posting tuple

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: nbtree: assertion failure in _bt_killitems() for posting tuple
Date: 2020-04-06 00:15:07
Message-ID: CAH2-Wz=BkEYkfYd2RuECmjgVnR8KVouEhfGV-30s7PGUtDU6mQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 24, 2020 at 1:00 AM Anastasia Lubennikova
<a(dot)lubennikova(at)postgrespro(dot)ru> wrote:
> > I think you're right. However, it still seems like we should check
> > that "kitem->indexOffset" is consistent among all of the BTScanPosItem
> > entries that we have for each TID that we believe to be from the same
> > posting list tuple.

The assertion failure happens in the logical replication worker
because it uses a dirty snapshot, which cannot release the pin per
commit 2ed5b87f. This means that the leaf page can change between the
time that we observe an item is dead, and the time we reach
_bt_killitems(), even though _bt_killitems() does get to kill items.

I am thinking about pushing a fix along the lines of the attached
patch. This preserves the assertion, while avoiding the check in cases
where it doesn't apply, such as when a dirty snapshot is in use.

--
Peter Geoghegan

Attachment Content-Type Size
v1-0001-Fix-assertion-failure-in-_bt_killitems.patch application/octet-stream 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-04-06 00:46:31 Re: [HACKERS] WAL logging problem in 9.4.3?
Previous Message Andres Freund 2020-04-06 00:07:15 Re: CLOBBER_CACHE_ALWAYS regression instability