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

Great!  Thank you Michael and Tomas!

Maybe a clue to the issue, why does a numrange need to be detoasted since
that is for large strings?

Let me know how I can further help.

Cheers,
Adam


On Mon, Nov 18, 2019 at 5:48 PM Michael Paquier <michael@paquier.xyz> wrote:

> 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
>