From: | pabloa98 <pabloa98(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: postgresql v11.1 Segmentation fault: signal 11: by running SELECT... JIT Issue? |
Date: | 2019-02-12 16:31:11 |
Message-ID: | CAEjudX6Ftn0CjbL0UqKwn+sLEGwCUaVKT8NwdVRBa1uW-mYcfw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I tried. It works
Thanks for the information.
P
On Mon, Jan 28, 2019, 7:28 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> pabloa98 <pabloa98(at)gmail(dot)com> writes:
> > I just migrated our databases from PostgreSQL version 9.6 to version
> 11.1.
> > We got a segmentation fault while running this query:
>
> > SELECT f_2110 as x FROM baseline_denull
> > ORDER BY eid ASC
> > limit 500
> > OFFSET 131000;
>
> > the table baseline_denull has 1765 columns, mainly numbers, like:
>
> Hm, that sounds like it matches this recent bug fix:
>
> Author: Andres Freund <andres(at)anarazel(dot)de>
> Branch: master [b23852766] 2018-11-27 10:07:03 -0800
> Branch: REL_11_STABLE [aee085bc0] 2018-11-27 10:07:43 -0800
>
> Fix jit compilation bug on wide tables.
>
> The function generated to perform JIT compiled tuple deforming failed
> when HeapTupleHeader's t_hoff was bigger than a signed int8. I'd
> failed to realize that LLVM's getelementptr would treat an int8 index
> argument as signed, rather than unsigned. That means that a hoff
> larger than 127 would result in a negative offset being applied. Fix
> that by widening the index to 32bit.
>
> Add a testcase with a wide table. Don't drop it, as it seems useful to
> verify other tools deal properly with wide tables.
>
> Thanks to Justin Pryzby for both reporting a bug and then reducing it
> to a reproducible testcase!
>
> Reported-By: Justin Pryzby
> Author: Andres Freund
> Discussion: https://postgr.es/m/20181115223959.GB10913@telsasoft.com
> Backpatch: 11, just as jit compilation was
>
>
> This would result in failures on wide rows that contain some null
> entries. If your table is mostly-not-null, that would fit the
> observation that it only crashes on a few rows.
>
> Can you try REL_11_STABLE branch tip and see if it works for you?
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Arjun Ranade | 2019-02-12 16:32:54 | pg_dump on a standby for a very active master |
Previous Message | Vikas Sharma | 2019-02-12 16:20:09 | Out of memory: Kill process nnnn (postmaster) score nn or sacrifice child |