From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Andreas Joseph Krogh <andreas(at)visena(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: ERROR: failed to add item to the index page |
Date: | 2019-05-01 01:28:11 |
Message-ID: | CAH2-WzmCMHuVcK8at7RSN0JLU6-XSdsoPbacEuPxTuV7XXcN6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 30, 2019 at 10:58 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:j
> I have found what the problem is. I simply neglected to make a
> conservative assumption about suffix truncation needing to add a heap
> TID to a leaf page's new high key in nbtsort.c (following commit
> dd299df8189), even though I didn't make the same mistake in
> nbtsplitloc.c. Not sure how I managed to make such a basic error.
Attached is a much more polished version of the same patch. I tried to
make clear how the "page full" test (the test that has been fixed to
take heap TID space for high key into account) is related to other
close-by code, such as the tuple space limit budget within
_bt_check_third_page(), and the code that sets up an actual call to
_bt_truncate().
I'll wait a few days before pushing this. This version doesn't feel
too far off being committable. I tested it with some of the CREATE
INDEX tests that I developed during development of the nbtree unique
keys project, including a test with tuples that are precisely at the
1/3 of a page threshold. The new definition of 1/3 of a page takes
high key heap TID overhead into account -- see _bt_check_third_page().
--
Peter Geoghegan
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Fix-nbtsort.c-s-page-space-accounting.patch | application/octet-stream | 6.2 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2019-05-01 01:34:42 | Re: Adding a test for speculative insert abort case |
Previous Message | Peter Geoghegan | 2019-05-01 00:58:35 | Re: Improve search for missing parent downlinks in amcheck |