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:
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!
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?