From: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
---|---|
To: | pgsql-committers(at)postgresql(dot)org |
Subject: | pgsql: Fix crasher bug in array_position(s) |
Date: | 2016-12-09 15:44:28 |
Message-ID: | E1cFNLY-0004p4-Ex@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
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.
Branch
------
REL9_6_STABLE
Details
-------
http://git.postgresql.org/pg/commitdiff/79c89f1f4e939b7a3f3bb4a76476dcda651cd58b
Modified Files
--------------
src/backend/utils/adt/array_userfuncs.c | 6 ++++--
src/test/regress/expected/arrays.out | 14 ++++++++++++++
src/test/regress/sql/arrays.sql | 9 +++++++++
3 files changed, 27 insertions(+), 2 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2016-12-09 17:01:50 | pgsql: Fix reporting of column typmods for multi-row VALUES constructs. |
Previous Message | Alvaro Herrera | 2016-12-09 14:51:47 | Re: Re: [COMMITTERS] pgsql: Permit dump/reload of not-too-large >1GB tuples |