summaryrefslogtreecommitdiff
path: root/src/backend/executor
diff options
context:
space:
mode:
authorAlvaro Herrera <alvherre@alvh.no-ip.org>2015-07-30 15:07:19 -0300
committerAlvaro Herrera <alvherre@alvh.no-ip.org>2015-07-30 15:07:19 -0300
commit244c378e243e3649efc99fe96ec9f123bbe9ffbc (patch)
tree1bc0f3a6f9cc8e6f09d5f08332de7daa769e3f85 /src/backend/executor
parent7be60a2459135199f8edff7f553b6d551729d79f (diff)
Fix broken assertion in BRIN code
The code was assuming that any NULL value in scan keys was due to IS NULL or IS NOT NULL, but it turns out to be possible to get them with other operators too, if they are used in contrived-enough ways. Easiest way out of the problem seems to check explicitely for the IS NOT NULL flag, instead of assuming it must be set if the IS NULL flag is not set, when a null scan key is found; if neither flag is set, follow the lead of other index AMs and assume that all indexable operators must be strict, and thus the query is never satisfiable. Also, add a comment to try and lure some future hacker into improving analysis of scan keys in brin. Per report from Andreas Seltenreich; diagnosis by Tom Lane. Backpatch to 9.5. Discussion: http://www.postgresql.org/message-id/20646.1437919632@sss.pgh.pa.us
Diffstat (limited to 'src/backend/executor')
0 files changed, 0 insertions, 0 deletions