On Fri, May 17, 2024 at 3:42 PM Mark Dilger <mark.dil...@enterprisedb.com> wrote: > On further review, the test was not anticipating the error message "high key > invariant violated for index". That wasn't seen in calls to > bt_index_parent_check(), but appears as one of the errors from > bt_index_check(). I am rerunning the test now....
Many different parts of the B-Tree code will fight against allowing duplicates of the same value to span multiple leaf pages -- this is especially true for unique indexes. For example, nbtsplitloc.c has a variety of strategies that will prevent choosing a split point that necessitates including a distinguishing heap TID in the new high key. In other words, nbtsplitloc.c is very aggressive about picking a split point between (rather than within) groups of duplicates. Of course it's still *possible* for a unique index to have multiple leaf pages containing the same individual value. The regression tests do have coverage for certain relevant code paths (e.g., there is coverage for code paths only hit when _bt_check_unique has to go to the page to the right). This is only the case because I went out of my way to make sure of it, by adding tests that allow a huge number of version duplicates to accumulate within a unique index. (The "move right" _bt_check_unique branches had zero test coverage for a year or two.) Just how important it is that amcheck covers cases where the version duplicates span multiple leaf pages is of course debatable -- it's always better to be more thorough, when practical. But it's certainly something that needs to be assessed based on the merits. -- Peter Geoghegan
