On Tue, Apr 30, 2019 at 10:58 AM Peter Geoghegan <p...@bowt.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
v2-0001-Fix-nbtsort.c-s-page-space-accounting.patch
Description: Binary data
