I finally pushed this fix.
In the end I both relaxed the assert a little bit to allow calling
build_distances for a single range, and added a bail out so that the
caller gets regular NULL and not whatever palloc(0) produces.
Thanks again for the report!
regards
--
Tomas Vondra
EnterpriseDB: h
On 11/9/22 00:13, Justin Pryzby wrote:
> On Mon, Oct 03, 2022 at 10:29:38PM +0200, Tomas Vondra wrote:
>> I'll get this fixed in a couple days. Considering the benign nature of
>> this issue (unnecessary assert) I'm not going to rush.
>
> Is this still an outstanding issue ?
>
Yes. I'll get it f
On Mon, Oct 03, 2022 at 10:29:38PM +0200, Tomas Vondra wrote:
> I'll get this fixed in a couple days. Considering the benign nature of
> this issue (unnecessary assert) I'm not going to rush.
Is this still an outstanding issue ?
--
Justin
On Mon, Oct 03, 2022 at 10:29:38PM +0200, Tomas Vondra wrote:
> On 10/3/22 21:25, Jaime Casanova wrote:
> > On Mon, Oct 03, 2022 at 07:53:34PM +0200, Tomas Vondra wrote:
> >> On 9/29/22 08:53, Jaime Casanova wrote:
> >>> ...
> >>>
> >>> Just found one more ocurrance of this one with this index whil
On 10/3/22 21:25, Jaime Casanova wrote:
> On Mon, Oct 03, 2022 at 07:53:34PM +0200, Tomas Vondra wrote:
>> On 9/29/22 08:53, Jaime Casanova wrote:
>>> ...
>>>
>>> Just found one more ocurrance of this one with this index while an
>>> autovacuum was running:
>>>
>>> """
>>> CREATE INDEX bt_f8_heap_s
On Mon, Oct 03, 2022 at 07:53:34PM +0200, Tomas Vondra wrote:
> On 9/29/22 08:53, Jaime Casanova wrote:
> > ...
> >
> > Just found one more ocurrance of this one with this index while an
> > autovacuum was running:
> >
> > """
> > CREATE INDEX bt_f8_heap_seqno_idx
> > ON public.bt_f8_heap
>
On 9/29/22 08:53, Jaime Casanova wrote:
> ...
>
> Just found one more ocurrance of this one with this index while an
> autovacuum was running:
>
> """
> CREATE INDEX bt_f8_heap_seqno_idx
> ON public.bt_f8_heap
> USING brin (seqno float8_minmax_multi_ops);
> """
> Attached is a backtrace
On Sun, Apr 04, 2021 at 07:52:50PM +0200, Tomas Vondra wrote:
> On 4/4/21 7:25 AM, Jaime Casanova wrote:
> >
> > pgbench -i postgres
> > psql -c "CREATE INDEX ON pgbench_history USING brin (tid
> > int4_minmax_multi_ops);" postgres
> > pgbench -c2 -j2 -T 300 -n postgres
> >
>
> Fixed and pushed
BTW, for the inet data type, I considered simply calling the "minus"
function, but that does not work because of this strange behavior:
int4=# select '10.1.1.102/32'::inet > '10.1.1.142/24'::inet;
?column?
--
t
(1 row)
int4=# select '10.1.1.102/32'::inet - '10.1.1.142/24'::inet;
?colu
On 4/4/21 7:25 AM, Jaime Casanova wrote:
> ...
> Changing to using month of 30 days on the formula fixed it.
>
I've pushed fixes for all the bugs reported in this thread so far
(mostly distance calculations, ...), and one bug (swapped operator
parameters in one place) I discovered while working o
On Thu, Apr 01, 2021 at 03:22:59PM +0200, Tomas Vondra wrote:
> On 4/1/21 3:09 PM, Zhihong Yu wrote:
> > Hi,
> > Can you try this patch ?
> >
> > Thanks
> >
> > diff --git a/src/backend/access/brin/brin_minmax_multi.c
> > b/src/backend/access/brin/brin_minmax_multi.c
> > index 70109960e8..25d6d2e
Hi, Tomas:
Thanks for the correction.
I think switching to interval_cmp_value() would be better (with a comment
explaining why).
Cheers
On Thu, Apr 1, 2021 at 6:23 AM Tomas Vondra
wrote:
> On 4/1/21 3:09 PM, Zhihong Yu wrote:
> > Hi,
> > Can you try this patch ?
> >
> > Thanks
> >
> > diff --g
On 4/1/21 3:09 PM, Zhihong Yu wrote:
> Hi,
> Can you try this patch ?
>
> Thanks
>
> diff --git a/src/backend/access/brin/brin_minmax_multi.c
> b/src/backend/access/brin/brin_minmax_multi.c
> index 70109960e8..25d6d2e274 100644
> --- a/src/backend/access/brin/brin_minmax_multi.c
> +++ b/src/backe
Hi,
Can you try this patch ?
Thanks
diff --git a/src/backend/access/brin/brin_minmax_multi.c
b/src/backend/access/brin/brin_minmax_multi.c
index 70109960e8..25d6d2e274 100644
--- a/src/backend/access/brin/brin_minmax_multi.c
+++ b/src/backend/access/brin/brin_minmax_multi.c
@@ -2161,7 +2161,7 @@
On Wed, Mar 31, 2021 at 6:19 PM Jaime Casanova
wrote:
>
> On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra
> wrote:
> >
> > Hi,
> >
> > I think I found the issue - it's kinda obvious, really. We need to
> > consider the timezone, because the "time" parts alone may be sorted
> > differently. The attac
On Thu, Apr 1, 2021 at 11:25 AM Tomas Vondra
wrote:
> As for why the regression tests did not catch this, it's most likely
> because the data is likely generated in "nice" ordering, or something
> like that. I'll see if I can tweak the ordering to trigger these issues
> reliably, and I'll do a bit
On 4/1/21 3:22 AM, Zhihong Yu wrote:
> Hi,
> - delta += (float8) addrb[i] - (float8) addra[i];
> - delta /= 256;
> ...
> + delta /= 255;
>
> May I know why the divisor was changed ?
>
Yeah, that's a mistake, it should remain 256. Consider two subtractions
1.1.2.255 - 1.1.1.0 =
Hi,
- delta += (float8) addrb[i] - (float8) addra[i];
- delta /= 256;
...
+ delta /= 255;
May I know why the divisor was changed ?
Thanks
On Wed, Mar 31, 2021 at 3:25 PM Tomas Vondra
wrote:
> Hi,
>
> I think I found the issue - it's kinda obvious, really. We need to
> conside
On Wed, Mar 31, 2021 at 5:25 PM Tomas Vondra
wrote:
>
> Hi,
>
> I think I found the issue - it's kinda obvious, really. We need to
> consider the timezone, because the "time" parts alone may be sorted
> differently. The attached patch should fix this, and it also fixes a
> similar issue in the ine
On 4/1/21 12:53 AM, Zhihong Yu wrote:
> Hi,
> For inet data type fix:
>
> + unsigned char a = addra[i];
> + unsigned char b = addrb[i];
> +
> + if (i >= lena)
> + a = 0;
> +
> + if (i >= lenb)
> + b = 0;
>
> Should the length check precede the addra[i]
Hi,
For inet data type fix:
+ unsigned char a = addra[i];
+ unsigned char b = addrb[i];
+
+ if (i >= lena)
+ a = 0;
+
+ if (i >= lenb)
+ b = 0;
Should the length check precede the addra[i] ?
Something like:
unsigned char a;
if (i >= lena)
Hi,
I think I found the issue - it's kinda obvious, really. We need to
consider the timezone, because the "time" parts alone may be sorted
differently. The attached patch should fix this, and it also fixes a
similar issue in the inet data type.
As for why the regression tests did not catch this,
On 3/31/21 8:20 PM, Zhihong Yu wrote:
> Hi,
> In build_distances():
>
> a1 = eranges[i].maxval;
> a2 = eranges[i + 1].minval;
>
> It seems there was overlap between the successive ranges, leading to
> delta = -678500
>
I've been unable to reproduce this, so far :-( How exact
Hi,
In build_distances():
a1 = eranges[i].maxval;
a2 = eranges[i + 1].minval;
It seems there was overlap between the successive ranges, leading to
delta = -678500
FYI
On Wed, Mar 31, 2021 at 10:30 AM Jaime Casanova <
jcasa...@systemguards.com.ec> wrote:
> Hi,
>
> Just found
24 matches
Mail list logo
