Re: BUG #18129: GiST index produces incorrect query results - Mailing list pgsql-bugs

From Heikki Linnakangas
Subject Re: BUG #18129: GiST index produces incorrect query results
Date
Msg-id 355c740d-0acf-0e09-df96-55b6c2804327@iki.fi
Whole thread Raw
In response to BUG #18129: GiST index produces incorrect query results  (PG Bug reporting form <noreply@postgresql.org>)
List pgsql-bugs
I just noticed that pgsql-bugs got dropped from this thread, so I'm 
resending this with pgsql-bugs CC'd

On 26/09/2023 13:10, Alexander Lakhin wrote:
> 26.09.2023 11:08, Alexander Lakhin wrote:
>>
>> And with the patch applied I get an assertion failure when the server
>> compiled --with-blocksize=1 (and -O0):
>> CPPFLAGS="-O0" ./configure -q --with-blocksize=1 --enable-debug --enable-cassert && make -s -j8 && make -s -j8 -C
>> contrib && make -s check -C contrib/intarray
>> not ok 1     - _int                                      806 ms
>> # (test process exited with exit code 2)
>> ^C# could not stop postmaster: exit code was 2
>>
>> (gdb) bt
>> #0  __pthread_kill_implementation (no_tid=0, signo=6, threadid=140373756303168) at ./nptl/pthread_kill.c:44
>> #1  __pthread_kill_internal (signo=6, threadid=140373756303168) at ./nptl/pthread_kill.c:78
>> #2  __GI___pthread_kill (threadid=140373756303168, signo=signo@entry=6) at ./nptl/pthread_kill.c:89
>> #3  0x00007fab4f409476 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26
>> #4  0x00007fab4f3ef7f3 in __GI_abort () at ./stdlib/abort.c:79
>> #5  0x0000559563a87ed9 in ExceptionalCondition (conditionName=0x559563b17a28 "ItemIdHasStorage(itemId)",
>> fileName=0x559563b17990 "../../../../src/include/storage/bufpage.h", lineNumber=355) at assert.c:66
>>
>> (in fact it crashes even on `make check`)
> 
> My note about "-O0" was excessive — I see the failure even with "-O3", it
> just occurs not every time.
> And as to make check - that was the same issue as I reported before (bug
> #18127).
> Sorry for the noise.
> 
> As to the assertion failure, maybe it's explained by the line
> maxoff = PageGetMaxOffsetNumber(parent->page);
> removed inside the while loop (I guess that maxoff recalculation is needed
> as parent->page changes inside the loop).

Yes, you're right. Fixed that, and pushed (commit 28d3c2ddcf). Thanks 
for the report and debugging!

-- 
Heikki Linnakangas
Neon (https://neon.tech)




pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #18142: strange behaviour of "UPDATE" with id_encode()
Next
From: PG Bug reporting form
Date:
Subject: BUG #18143: pg_upgrade fails to use port 50432 even with firewall disabled