BUG #15597: possible bug in amcheck/amcheck_next (or corrupted index?)

The following bug has been logged on the website:

Bug reference:      15597
Logged by:          Andreas Kunert
Email address:      kunert@cms.hu-berlin.de
PostgreSQL version: 11.1
Operating system:   Ubuntu 16.04.5 LTS
Description:

Hello,

I observed the following behavior in Postgres 9.6.?/10.6/11.1 running under
Debian/Debian/Ubuntu on three different servers:

CREATE TABLE foo
(
  a integer,
  b character(255),
  c character(255),
  d character(255),
  e character(25),
  g date,
  h date,
  i date,
  j character(255),
  k character(255),
  m character(10),
  n character(255),
  o character(1),
  p character(4),
  q character(1),
  r integer,
  t character(255),
  u character(50),
  v character(100)
);
CREATE INDEX i_foo ON foo USING btree (b COLLATE pg_catalog."default", c
COLLATE pg_catalog."default");

select oid, relname from pg_class where relname like 'i_foo';
-- result is e.g. 12345

select bt_index_check(12345, true);
-- result: everything ok

INSERT INTO foo(a,b,c,d,e,g,h,i,j,k,m,n,o,p,q,r,t,u,v) VALUES ('1', 'b',
'c', 'd', 'e', '2000-01-01', '2000-01-01', NULL, 'j', 'k', 'm', 'n', 'o',
'p', 'q', '2', 't', 'u', 'v'); 
-- result: ok

select bt_index_check(12345, true);
-- result: ERROR:  heap tuple (0,1) from table "foo" lacks matching index
tuple within index "i_foo"

reindex table foo;
select bt_index_check(12345, true);
-- result: everything ok again, but after adding another row:

INSERT INTO foo(a,b,c,d,e,g,h,i,j,k,m,n,o,p,q,r,t,u,v) VALUES ('1', 'b',
'c', 'd', 'e', '2000-01-01', '2000-01-01', NULL, 'j', 'k', 'm', 'n', 'o',
'p', 'q', '2', 't', 'u', 'v'); 

select bt_index_check(12345, true);
-- result: ERROR:  heap tuple (0,2) from table "foo" lacks matching index
tuple within index "i_foo"

Despite the error message I suspect the index being ok since I can find the
aforementioned tuples by using it:

explain select * from foo where b='b' and c='c'
-- result: Index Scan using i_foo on foo...
select * from foo where b='b' and c='c'
-- result: 2 rows

I tried to simplify the example table as much as possible - if I remove more
columns or reduce some of the char(n) lengths, the error does not appear.

Moreover I hope you can reproduce the behavior.

Regards,
Andreas