| From: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
|---|---|
| To: | Nitin Motiani <nitinmotiani(at)google(dot)com> |
| Cc: | 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-23 07:04:37 |
| Message-ID: | CAFiTN-sUiDN6ef-eONKhP6=Nz1sdaY6S9xHeaPtUgmVpuZ8ROg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Fri, Oct 16, 2026 at 2:45 PM Nitin Motiani <nitinmotiani(at)google(dot)com> wrote:
>
> Hi,
>
> Thanks for the analysis. I was able to reproduce the issue.
>
> On Thu, Oct 15, 2026 at 9:03 PM PG Bug reporting form
> <noreply(at)postgresql(dot)org> wrote:
> >
> > btree_ts.c avoids this. gbt_ts_penalty does its own double arithmetic on the
> > raw int64 values, gbt_ts_dist returns get_float8_infinity() for non-finite
> > input, and ts_dist/tstz_dist return a saturated interval.
> >
>
> I'm attaching a patch which uses the same logic as btree_ts.c and
> btree_int.c in btree_date.co to handle these issues. Please take a
> look.
So IIUC the issue relates to the btree date handling function and not
to gist? If so we can use a normal btree index in the new test cases
we have added instead of gist. I haven't yet reviewed the code
completely but I will do it soon.
--
Regards,
Dilip Kumar
Google
| From | Date | Subject | |
|---|---|---|---|
| Next Message | weijie JL | 2026-10-23 07:15:43 | Re: BUG #19725: PostgreSQL 18.6: pg_restore read failure with io_uring, not observed with worker |
| Previous Message | Richard Guo | 2026-10-23 06:47:30 | Re: BUG #19765: Wrong result from a chain of LEFT JOINs since v16 |