From 79c89f1f4e939b7a3f3bb4a76476dcda651cd58b Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Fri, 9 Dec 2016 12:42:17 -0300 Subject: 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. --- src/test/regress/sql/arrays.sql | 9 +++++++++ 1 file changed, 9 insertions(+) (limited to 'src/test/regress/sql/arrays.sql') diff --git a/src/test/regress/sql/arrays.sql b/src/test/regress/sql/arrays.sql index a2c3db11274..2fbc699f604 100644 --- a/src/test/regress/sql/arrays.sql +++ b/src/test/regress/sql/arrays.sql @@ -262,6 +262,15 @@ $$ LANGUAGE plpgsql; SELECT array_position('[2:4]={1,2,3}'::int[], 1); SELECT array_positions('[2:4]={1,2,3}'::int[], 1); +SELECT + array_position(ids, (1, 1)), + array_positions(ids, (1, 1)) + FROM +(VALUES + (ARRAY[(0, 0), (1, 1)]), + (ARRAY[(1, 1)]) +) AS f (ids); + -- operators SELECT a FROM arrtest WHERE b = ARRAY[[[113,142],[1,147]]]; SELECT NOT ARRAY[1.1,1.2,1.3] = ARRAY[1.1,1.2,1.3] AS "FALSE"; -- cgit v1.2.3