| From: | Andrey Borodin <amborodin86(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Jose Arthur Benetasso Villanova <jose(dot)arthur(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Amcheck verification of GiST and GIN |
| Date: | 2023-03-18 03:40:05 |
| Message-ID: | CAAhFRxh-c+xG6AsPvUw8jQEj73y8m6j8-MR2xmuk3D8d0Bj3Fg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Peter,
Thanks for the feedback! I'll work on it during the weekend.
On Thu, Mar 16, 2023 at 6:23 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> existence of a "same" routine hints at some confusion about "equality
> versus equivalence" issues.
Hmm...yes, actually, GiST deals with floats routinely. And there might
be some sorts of NaNs and Infs that are equal, but not binary
equivalent.
I'll think more about it.
gist_get_adjusted() calls "same" routine, which for type point will
use FPeq(double A, double B). And this might be kind of a corruption
out of the box. Because it's an epsilon-comparison, ε=1.0E-06.
GiST might miss newly inserted data, because the "adjusted" tuple was
"same" if data is in proximity of 0.000001 of any previously indexed
point, but out of known MBRs.
I'll try to reproduce this tomorrow, so far no luck.
Best regards, Andrey Borodin.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Kapila | 2023-03-18 04:11:59 | BF mamba failure |
| Previous Message | Michael Paquier | 2023-03-18 01:18:59 | Re: Add pg_walinspect function with block info columns |