Re: Index-only scan for btree_gist turns bpchar to char

07.01.2022 12:00, Alexander Lakhin wrote:
> Hello,
> 07.01.2022 09:26, Japin Li wrote:
>> On Fri, 07 Jan 2022 at 03:21, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>
>> In any case, if we do need same() to implement the identical
>> behavior to bpchareq(), then the other solution isn't sufficient
>> either.
>>
>> So in short, it seems like we ought to do some compatibility testing
>> and see if this code misbehaves at all with an index created by the
>> old code.  I don't particularly want to do that ... any volunteers?
>>
>> Thanks for your patch, it looks good to me.  I'm not sure how to test this.
> I will test it tomorrow.
I've made a simple test based on the regression test (see attachment)
and can confirm that REINDEX after upgrade fixes the index contents.

Differences after upgrade but before REINDEX:
--- /tmp/pgtest/char.out        2022-01-08 21:27:43.912274805 +0300
+++ /tmp/pgtest/char.expected   2022-01-08 21:27:43.896274765 +0300
@@ -40,8 +40,8 @@
 (2 rows)
 
 SELECT * FROM chartmp WHERE a BETWEEN '31a' AND '31c';
-  a  
-------
- 31b0
+                a                
+----------------------------------
+ 31b0                           
 (1 row)
 
REINDEX INDEX charidx
Differences after upgrade and REINDEX:
Files /tmp/pgtest/char.out and /tmp/pgtest/char.expected are identical

(Unfortunately for me) I found no anomalies related to gbt_text_same()
with an index created with the previous implementation. I've added
diagnostic logging that shows when gbt_text_same() returns 0 for keys
that are the equal but have different padding. So I've observed that
gbt_text_same() returns incorrect result, but all the btree_gist tests
still pass. Moreover, unconditional "*result = 0;" in gbt_text_same()
doesn't affect the tests at all.
I've found that gbt_text_same() is called by gistKeyIsEQ() from
backend/access/gist/gistutil.c, and made gistKeyIsEQ() return false any
time. And even with such change all check-world tests still pass (except
for isolation/predicate-gist that failed due to locking of pages split
differently). So for now, I still don't know how to get incorrect query
results due to incorrect gistKeyIsEQ() behavior/excessive page splitting.

Best regards,
Alexander