Date: Mon, 18 Nov 2019 13:50:20 +0900
From: Michael Paquier <michael@paquier.xyz>
To: adam.c.scott@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16122: segfault pg_detoast_datum (datum=0x0) at fmgr.c:1833
 numrange query
Message-ID: <20191118045020.GC1543@paquier.xyz>
References: <16122-eb35bc248c806c15@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="WplhKdTI2c8ulnbP"
Content-Disposition: inline
In-Reply-To: <16122-eb35bc248c806c15@postgresql.org>
Precedence: bulk


--WplhKdTI2c8ulnbP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi Adam,

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

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:
>=20
> 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=3D0xffffffff) at fmgr.c:1833
> #1  0x0000557a18c19545 in numeric_sub (fcinfo=3Dfcinfo@entry=3D0x7ffff579=
5e30)
>     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

--WplhKdTI2c8ulnbP
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAl3SIwwACgkQnvQgOdby
QH1Pdw/9Er2zvw+JWiIBQRG/AQJELUeGOVyK36ldt+PmzEp8KY2CyutpIvPsbXxl
wXFxpLO+IhwK+tnugAKaG5OdaNqc4WkCzlwAbqU4M01MGDAAAyUdNEObL45o6Mkn
pGLQ3lzZ7bWBt8hL1CCGXhRxP9GLxDFhD+5tkXu0NlaPc3iFMu9u0ZPpCUkHIZB8
jw05rqu9SigHJrXei4wUMtpI0NFtzHPmxP/U4K59gl/XDURIHbmK3pvXi5XP+82x
z9jQN81nDhf7Seqacdswj2rGppG9GlUqSnfuFbnZqMTHh1IzLWgvBZNiU08GYoXV
eHHW/qJoFN48URWWg6z1tvL9L8k+ar6nBGrSF04+Yw6Pp4Zobq0Fw6/WDVVbWO4o
F0+sh6J+YGVIkhGU8DMn9X2Gu9C9pGyjlJ5RZ5iWc/cqFGWXH6iwK/XU90UsGTPL
niZtW7j4TGXctpVTmvj967cOsTwA7MdXm42eBkiL1/emJeJc18JJ8ww2aPgLMw5n
erch3CDVaXeCOHcnM7RdVP06QakexWqyhNdx68SQtMU+hD4sOM40D4TNk5gyMp3m
kT6DnO5CkQiZJgOz8B7hFbVfWDRcmqA4zhyilpEt0g7rc1xWFvVIuPwHFx8FRRrZ
ubwT3feufaacVhHSGc2AvpKgMa6zd2LaLSoipXE+ZxkXkOnt/WY=
=3xi3
-----END PGP SIGNATURE-----

--WplhKdTI2c8ulnbP--