Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: adam(dot)c(dot)scott(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833 numrange query
Date: 2019-11-18 04:50:20
Message-ID: 20191118045020.GC1543@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Adam,

On Mon, Nov 18, 2019 at 01:27:22AM +0000, PG Bug reporting form wrote:
> Email address: adam(dot)c(dot)scott(at)gmail(dot)com
> PostgreSQL version: 10.11
> Operating system: Ubuntu &amp; CentOS
> Description:

Did you see that after updating to 10.11. If you used 10.10 or
an older version, did the problem happen?

> Seg fault can be repeated by running this query:
>
> select count(*) from natica_hdu where boundary is not null
> and
> "dec_range" <@ '[89.9999998611111,90.0000001388889)' AND "ra_range" <@
> '[45.0,45.1]';

It would help if we had a sample of data here able to reproduce the
problem. Something looks to be wrong with this range operator when
working on numeric ranges, still I cannot reproduce the problem with
for example stuff like that:
CREATE TABLE aa (a numrange);
CREATE INDEX aai ON aa(a);
INSERT INTO aa
SELECT ('['|| (90.0 - a::numeric/10000000000) || ',' ||
(90.0 + a::numeric/10000000000) || ')')::numrange
FROM generate_series(1,10000) as a;
SELECT count(*) FROM aa
WHERE a <@ '[89.9999998611111,90.0000001388889)';

Seeing the plan of your query may help as well. Could you run EXPLAIN
on it or does it crash before? Perhaps a parallel plan is involved
here?

> #0 pg_detoast_datum (datum=0xffffffff) at fmgr.c:1833
> #1 0x0000557a18c19545 in numeric_sub (fcinfo=fcinfo(at)entry=0x7ffff5795e30)
> at numeric.c:2288

Hmm. Per the shape of this backtrace, you are indeed processing the
range operator, and this portion of memory looks freed. My simplified
example above basically goes through the same when planning the
query.
--
Michael

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2019-11-18 05:37:53 BUG #16123: DST not respected for America/Sao_Paulo in `timestamp` function
Previous Message Michael Paquier 2019-11-18 04:14:33 Re: incorrect pg_dump output due to not handling dropped roles correctly