diff options
author | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2016-12-09 12:42:17 -0300 |
---|---|---|
committer | Alvaro Herrera <alvherre@alvh.no-ip.org> | 2016-12-09 12:42:17 -0300 |
commit | 79c89f1f4e939b7a3f3bb4a76476dcda651cd58b (patch) | |
tree | 75bd72b6b8d0ff708f46b55a4988cb1ca696d48c /src/backend/parser/parse_relation.c | |
parent | 86c6aaff6ead3e00a89fd0743195678bbc69790c (diff) | |
download | postgresql-79c89f1f4e939b7a3f3bb4a76476dcda651cd58b.tar.gz postgresql-79c89f1f4e939b7a3f3bb4a76476dcda651cd58b.zip |
Fix crasher bug in array_position(s)
array_position and its cousin array_positions were caching the element
type equality function's FmgrInfo without being careful enough to put it
in a long-lived context. This is obviously broken but it didn't matter
in most cases; only when using arrays of records (involving record_eq)
it becomes a problem. The fix is to ensure that the type's equality
function's FmgrInfo is cached in the array_position's flinfo->fn_mcxt
rather than the current memory context.
Apart from record types, the only other case that seems complex enough
to possibly cause the same problem are range types. I didn't find a way
to reproduce the problem with those, so I only include the test case
submitted with the bug report as regression test.
Bug report and patch: Junseok Yang
Discussion: https://postgr.es/m/CAE+byMupUURYiZ6bKYgMZb9pgV1CYAijJGqWj-90W=nS7uEOeA@mail.gmail.com
Backpatch to 9.5, where array_position appeared.
Diffstat (limited to 'src/backend/parser/parse_relation.c')
0 files changed, 0 insertions, 0 deletions