Re: BUG #19761: btree_gist: "cannot subtract infinite dates" when inserting 'infinity' into a GiST index on date

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Nitin Motiani <nitinmotiani(at)google(dot)com>
Cc: Dilip Kumar <dilipbalaut(at)gmail(dot)com>, alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19761: btree_gist: "cannot subtract infinite dates" when inserting 'infinity' into a GiST index on date
Date: 2026-10-26 16:10:46
Message-ID: 638642.1793031046@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Nitin Motiani <nitinmotiani(at)google(dot)com> writes:
> Thanks for the review, Dilip. I'm attaching the v2 patch which makes
> the change in date_dist also.

I think this is not there yet. An important behavior of the
corresponding code for float8 (float_penalty_num_impl()) is that
it makes the distance between two same-sign infinity values be zero,
not infinity. This is mathematically wrong but we must do it for
indexing purposes, else inserting multiple infinities will end up
splitting each infinity onto its own index page when we want all
identical infinities to pack onto as few index pages as possible.

BTW, while checking this I happened to notice that
gbt_float8_dist has a variant of the same problem:

r = arg1 - arg2;
if (unlikely(isinf(r)) && !isinf(arg1) && !isinf(arg2))
float_overflow_error();

I don't think we want an error thrown there either;
returning the infinite distance (or DBL_MAX?) seems better.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message PG Bug reporting form 2026-10-26 16:58:54 BUG #19799: Self-join elimination: "failed to build any 3-way joins" with LATERAL
Previous Message Manu 2026-10-26 15:41:19 Re: BUG #19760: CLUSTER loses a row the transaction inserted and then updated in a rolled-back subtransaction