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  (Adam Scott <adam.c.scott@gmail.com>)
Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: REINDEX CONCURRENTLY unexpectedly fails
Следующее
От: Adam Scott
Дата:
Сообщение: Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833numrange query