Обсуждение: Missing SELECT output on btree_gin char, BTLess* strategy

The expected output in contrib/btree_gin/expected/char.out is wrong for the
first two SELECTs using the BTLess* strategies: they should not be empty.

    set enable_seqscan=off;

    CREATE TABLE test_char (
            i "char"
    );

    INSERT INTO test_char VALUES ('a'),('b'),('c'),('d'),('e'),('f');

    CREATE INDEX idx_char ON test_char USING gin (i);

    SELECT * FROM test_char WHERE i<'d'::"char" ORDER BY i;
    SELECT * FROM test_char WHERE i<='d'::"char" ORDER BY i;

gives

     i
    ---
    (0 rows)

     i
    ---
    (0 rows)

If Bitmap Scan is turned off, we get output, as expected:

    set enable_bitmapscan=off;
    SELECT * FROM test_char WHERE i<'d'::"char" ORDER BY i;
    SELECT * FROM test_char WHERE i<='d'::"char" ORDER BY i;

gives

     i
    ---
     a
     b
     c
    (3 rows)

     i
    ---
     a
     b
     c
     d
    (4 rows)

I tried the following and got the same results:

- Do the inserts after the CREATE INDEX.
- Create the index with fastupdate turned off: CREATE INDEX ... WITH
  (fastupdate = off).
- Reconnect (and don't forget to disable sequential scan).
- Stop and start the server: pg_ctl restart.

I'm on 15devel, but this issue appears to have been around for years.

On Mon, Aug 9, 2021 at 6:15 PM Jason Kim <git@jasonk.me> wrote:
> The expected output in contrib/btree_gin/expected/char.out is wrong for the
> first two SELECTs using the BTLess* strategies: they should not be empty.

Isn't this index corruption, or at least an inconsistent opclass? It
may be true that the tests show the wrong output, and always have. But
isn't the more concerning problem that the index gives wrong answers
in general, not the tests?

-- 
Peter Geoghegan

Peter Geoghegan <pg@bowt.ie> writes:
> On Mon, Aug 9, 2021 at 6:15 PM Jason Kim <git@jasonk.me> wrote:
>> The expected output in contrib/btree_gin/expected/char.out is wrong for the
>> first two SELECTs using the BTLess* strategies: they should not be empty.

> Isn't this index corruption, or at least an inconsistent opclass?

Indeed.  After a bit of poking around, I realized that btree_gin's
leftmostvalue_char() is not on the same page as btcharcmp() about
whether type "char" is signed or unsigned.

AFAICT, only the latter function matters while making index entries,
while the wrong value from leftmostvalue_char() affects only search
results.  So we can just fix it, as attached.

            regards, tom lane

diff --git a/contrib/btree_gin/btree_gin.c b/contrib/btree_gin/btree_gin.c
index e05b5c60ca..c50d68ce18 100644
--- a/contrib/btree_gin/btree_gin.c
+++ b/contrib/btree_gin/btree_gin.c
@@ -357,7 +357,7 @@ GIN_SUPPORT(bpchar, true, leftmostvalue_text, bpcharcmp)
 static Datum
 leftmostvalue_char(void)
 {
-    return CharGetDatum(SCHAR_MIN);
+    return CharGetDatum(0);
 }

 GIN_SUPPORT(char, false, leftmostvalue_char, btcharcmp)
diff --git a/contrib/btree_gin/expected/char.out b/contrib/btree_gin/expected/char.out
index 09e0315de0..6563546d3c 100644
--- a/contrib/btree_gin/expected/char.out
+++ b/contrib/btree_gin/expected/char.out
@@ -7,12 +7,19 @@ CREATE INDEX idx_char ON test_char USING gin (i);
 SELECT * FROM test_char WHERE i<'d'::"char" ORDER BY i;
  i
 ---
-(0 rows)
+ a
+ b
+ c
+(3 rows)

 SELECT * FROM test_char WHERE i<='d'::"char" ORDER BY i;
  i
 ---
-(0 rows)
+ a
+ b
+ c
+ d
+(4 rows)

 SELECT * FROM test_char WHERE i='d'::"char" ORDER BY i;
  i