I tried. It works Thanks for the information. P On Mon, Jan 28, 2019, 7:28 PM Tom Lane <t...@sss.pgh.pa.us> wrote:
> pabloa98 <pablo...@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 <and...@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.gb10...@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 >
