Re: postgresql v11.1 Segmentation fault: signal 11: by runningSELECT... JIT Issue?

pabloa98 <pabloa98@gmail.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@anarazel.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