Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
От | Tom Lane |
---|---|
Тема | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan |
Дата | |
Msg-id | 3000247.1712537309@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: Optimizing nbtree ScalarArrayOp execution, allowing multi-column ordered scans, skip scan
|
Список | pgsql-hackers |
Coverity pointed out something that looks like a potentially live problem in 5bf748b86: /srv/coverity/git/pgsql-git/postgresql/src/backend/access/nbtree/nbtutils.c: 2950 in _bt_preprocess_keys() 2944 * need to make sure that we don't throw away an array 2945 * scan key. _bt_compare_scankey_args expects us to 2946 * always keep arrays (and discard non-arrays). 2947 */ 2948 Assert(j == (BTEqualStrategyNumber - 1)); 2949 Assert(xform[j].skey->sk_flags & SK_SEARCHARRAY); >>> CID 1596256: Null pointer dereferences (FORWARD_NULL) >>> Dereferencing null pointer "array". 2950 Assert(xform[j].ikey == array->scan_key); 2951 Assert(!(cur->sk_flags & SK_SEARCHARRAY)); 2952 } 2953 } 2954 else if (j == (BTEqualStrategyNumber - 1)) Above this there is an assertion Assert(!array || array->num_elems > 0); which certainly makes it look like array->scan_key could be a null-pointer dereference. regards, tom lane
В списке pgsql-hackers по дате отправления: