Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query
От | Michael Paquier |
---|---|
Тема | Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query |
Дата | |
Msg-id | 20191119014827.GC1614@paquier.xyz обсуждение исходный текст |
Ответ на | Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query (Adam Scott <adam.c.scott@gmail.com>) |
Ответы |
Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query
Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query |
Список | pgsql-bugs |
On Mon, Nov 18, 2019 at 03:59:14PM -0800, Adam Scott wrote: > It was bugging out with an empty table but it seems intermittent. A > successful query followed by the one above will not fail sometimes; hence > the need for a from-scratch startup instance of postgres. Okay, that has proved to help a lot. I have restored the dump, and after an analyze on natica_hdu_test I can see the failure immediately. I have also extracted a small test case able to reproduce the failure. That's actually pretty close to the scenarios I was playing with upthread, still I missed it: CREATE TABLE rangetab (a numrange); INSERT INTO rangetab SELECT ('['|| (45.0 - a::numeric/10000000) || ',' || (45.1 + a::numeric/10000000) || ')')::numrange FROM generate_series(1,1000) as a; ANALYZE rangetab; SELECT a FROM rangetab WHERE a <@ '[89.9999998611111,90.0000001388889)'; I can easily reproduce the failure on HEAD, REL_12_STABLE and REL_11_STABLE. On 10, I could not. But now that we have a test case that's only a matter of time. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: