aboutsummaryrefslogtreecommitdiff
path: root/src/test/modules/test_json_parser/test_json_parser_incremental.c
diff options
context:
space:
mode:
authorPeter Geoghegan <pg@bowt.ie>2024-04-22 13:58:06 -0400
committerPeter Geoghegan <pg@bowt.ie>2024-04-22 13:58:06 -0400
commit480bc6e3ed3a5719cdec076d4943b119890e8171 (patch)
tree52776748486be718f2810c8d1edc2eb65588111a /src/test/modules/test_json_parser/test_json_parser_incremental.c
parent7e44ac3741dd2ebf8c668d6ac6a10fa6ed7301b3 (diff)
downloadpostgresql-480bc6e3ed3a5719cdec076d4943b119890e8171.tar.gz
postgresql-480bc6e3ed3a5719cdec076d4943b119890e8171.zip
Remove unneeded nbtree array preprocessing assert.
Certain cases involving the use of cursors had assertion failures within _bt_preprocess_keys's recently added no-op return path. The assertion in question made the faulty assumption that a second or third call to _bt_preprocess_keys (within the same btrescan) could only happen when another scheduled primitive index scan was just about to begin. It would be possible to address the problem by only allowing scans that have array keys to take the new no-op path, forcing affected cases to perform redundant preprocessing work. It seems simpler to just remove the assertion, and reframe the no-op path as a more general mechanism. Take this simpler approach. The important underlying principle is that we only need to perform preprocessing once per btrescan (at most). This is expected regardless of whether or not the scan happens to have array keys. Oversight in commit 1b134ca5, which enhanced nbtree ScalarArrayOp execution. Reported-By: Alexander Lakhin <exclusion@gmail.com> Discussion: https://postgr.es/m/ef0f7c8b-a6fa-362e-6fd6-054950f947ca@gmail.com
Diffstat (limited to 'src/test/modules/test_json_parser/test_json_parser_incremental.c')
0 files changed, 0 insertions, 0 deletions