| From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
|---|---|
| To: | Junseok Yang <jsyang(at)bitnine(dot)net> |
| Cc: | PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Subject: | Re: `array_position...()` causes SIGSEGV |
| Date: | 2016-12-09 07:24:38 |
| Message-ID: | CAB7nPqT6-MbMtR=rN6tQEiE-t3ZxYDiRn-BCU=hT5G-511BKKQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Dec 9, 2016 at 3:14 PM, Junseok Yang <jsyang(at)bitnine(dot)net> wrote:
> I met SIGSEGV when using `array_position()` with record type
> arguments, so I've written a patch which corrects this problem. It
> seems that `array_position...()` sets wrong memory context for the
> cached function (in this case `record_eq()`) which is used to find a
> matching element.
>
> The problem is reproducable with the following query.
>
> SELECT array_position(ids, (1, 1))
> FROM (VALUES (ARRAY[(0, 0)]), (ARRAY[(1, 1)])) AS _(ids);
Good catch. That's present since 13dbc7a8 and the introduction of
array_offset(), or array_position() on HEAD, so the patch should be
applied down to 9.5.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2016-12-09 08:06:24 | Re: Password identifiers, protocol aging and SCRAM protocol |
| Previous Message | Michael Paquier | 2016-12-09 07:11:26 | Re: Hang in pldebugger after git commit : 98a64d0 |