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

Hi Adam,

thanks for the report.

On Mon, Nov 18, 2019 at 01:27:22AM +0000, PG Bug reporting form wrote:
>The following bug has been logged on the website:
>
>Bug reference:      16122
>Logged by:          ascott
>Email address:      adam.c.scott@gmail.com
>PostgreSQL version: 10.11
>Operating system:   Ubuntu & CentOS
>Description:
>
>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 crashes on this line:
>
>if (VARATT_IS_EXTENDED(datum)) in fmgr.c:1833
>
>GDB stacktrace is below.
>

Hmmm, this does seem like some sort of memory/data corruption, probably.
But I'm unable to reproduce the issue, it's likely data dependent. Can
you try extracting a data set reproducing the issue? Not sure how large
or sensitive the data is, but if needed you can share it off-list.

>The table definition for natica_hdu is as follows:
>CREATE TABLE public.natica_hdu
>(
>  id integer NOT NULL,
>  updated timestamp with time zone NOT NULL,
>  hdu_idx smallint NOT NULL,
>  ra double precision,
>  "dec" double precision,
>  boundary double precision[],
>  extras jsonb NOT NULL,
>  fitsfile_id character varying(32) NOT NULL,
>  dec_range numrange,
>  ra_range numrange
>)
>WITH (
>  OIDS=FALSE
>);

Hm, the query only really touches dec_range and ra_range. If you try
just 

   select count(*) from natica_hdu
   where "dec_range" <@ '[89.9999998611111,90.0000001388889)'

and

   select count(*) from natica_hdu
   where "ra_range" <@ '[45.0,45.1]'

does either of those queries crash too? That would reduce the amount of
data for the reproducer.

If you try just

   COPY (SELECT ra_range, dec_range FROM public.natica_hdu) TO '/dev/null';

does that fail too? If yes, it's likely due to on-disk data corruption.
If not, it seems more like a memory corruption during processing.

I think the grants and indexes are mostly irrelevant for the issue,
particularly those not related to columns in the query.  Did you include
just because they are defined, or because you think it's actually
related?

>ALTER TABLE public.natica_hdu
>  OWNER TO postgres;
>
>CREATE INDEX natica_hdu_dec_range_56c7d92d
>  ON public.natica_hdu
>  USING btree
>  (dec_range);
>
>CREATE INDEX natica_hdu_fitsfile_id_3a3363fe
>  ON public.natica_hdu
>  USING btree
>  (fitsfile_id COLLATE pg_catalog."default");
>
>CREATE INDEX natica_hdu_fitsfile_id_3a3363fe_like
>  ON public.natica_hdu
>  USING btree
>  (fitsfile_id COLLATE pg_catalog."default" varchar_pattern_ops);
>
>
>CREATE INDEX natica_hdu_q3c_ang2ipix_idx
>  ON public.natica_hdu
>  USING btree
>  (q3c_ang2ipix(ra, "dec"));
>ALTER TABLE public.natica_hdu CLUSTER ON natica_hdu_q3c_ang2ipix_idx;
>
>CREATE INDEX natica_hdu_ra_range_b9f4d3ac
>  ON public.natica_hdu
>  USING btree
>  (ra_range);

...

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services