- Notifications
You must be signed in to change notification settings - Fork5.2k
Commit7c365eb
committed
Make handling of redundant nbtree keys more robust.
nbtree preprocessing's handling of redundant (and contradictory) keyscreated problems for scans with = arrays. It was just about possiblefor a scan with an = array key and one or more redundant keys (keys thatpreprocessing could not eliminate due an incomplete opfamily and across-type key) to get stuck. Testing has shown that infinite cyclingwhere the scan never manages to make forward progress was possible.This could happen when the scan's arrays were reset in _bt_readpage'sforcenonrequired=true path (added by bugfix commit5f4d98d) when thearrays weren't at least advanced up to the same point that they were inat the start of the _bt_readpage call. Earlier redundant keys preventedthe finaltup call to _bt_advance_array_keys from reaching lower-orderkeys that needed to be used to sufficiently advance the scan's arrays.To fix, make preprocessing leave the scan's keys in a state that is asclose as possible to how it'll usually leave them (in the common casewhere there's no redundant keys that preprocessing failed to eliminate).Now nbtree preprocessing _reliably_ leaves behind at most one required>/>= key per index column, and at most one required </<= key per indexcolumn. Columns that have one or more = keys that are eligible to bemarked required (based on the traditional rules) prioritize the = keysover redundant inequality keys; they'll _reliably_ be left with only oneof the = keys as the index column's only required key.Keys that are not marked required (whether due to the new preprocessingstep running or for some other reason) are relocated to the end of theso->keyData[] array as needed. That way they'll always be evaluatedafter the scan's required keys, and so cannot prevent code in placeslike _bt_advance_array_keys and _bt_first from reaching a required key.Also teach _bt_first to decide which initial positioning keys to usebased on the same requiredness markings that have long been used by_bt_checkkeys/_bt_advance_array_keys. This is a necessary condition forreliably avoiding infinite cycling. _bt_advance_array_keys expects tobe able to reason about what'll happen in the next _bt_first call shouldit start another primitive index scan, by evaluating inequality keysthat were marked required in the opposite-to-scan scan direction only.Now everybody (_bt_first, _bt_checkkeys, and _bt_advance_array_keys)will always agree on which exact key will be used on each index columnto start and/or end the scan (except when row compare keys are involved,which have similar problems not addressed by this commit).An upcoming commit will finish off the work started by this commit byharmonizing how _bt_first, _bt_checkkeys, and _bt_advance_array_keysapply row compare keys to start and end scans.This fixes what was arguably an oversight in either commit5f4d98d orcommit8a51027.Author: Peter Geoghegan <pg@bowt.ie>Reviewed-By: Heikki Linnakangas <heikki.linnakangas@iki.fi>Discussion:https://postgr.es/m/CAH2-Wz=ds4M+3NXMgwxYxqU8MULaLf696_v5g=9WNmWL2=Uo2A@mail.gmail.comBackpatch-through: 181 parent87f0d3c commit7c365eb
File tree
3 files changed
+455
-269
lines changed- src/backend/access/nbtree
3 files changed
+455
-269
lines changed0 commit comments
Comments
(0)