Re: BUG #19638: Planner chooses an index-only scan for an index AM without amcanreturn, and execution fails

Andrey -- thank you for the independent confirmation, and for the pointer
to 74197bdc842, which is a better reference than the thread title I had.

David: re-attaching nokeyam.tar.gz here in case it did not survive my
previous message. Same module as described: dummy_index_am plus
amoptionalkey = true, an amgettuple returning one heap TID, and
amcanreturn left NULL.

One thing I have not seen mentioned yet, which may matter for the fix and
for whatever test you settle on: the trigger is not count(*), it is any
query whose target list needs no attribute from the index. Measured on
18.6 with the module above, seqscan and bitmapscan off:

SELECT COUNT(*) FROM t_nokey; Index Only Scan -> ERROR
SELECT FROM t_nokey; Index Only Scan -> ERROR
SELECT EXISTS (SELECT 1 FROM t_nokey); Index Only Scan -> ERROR

SELECT a FROM t_nokey; Seq Scan (disabled) -> correct
SELECT b FROM t_nokey; Seq Scan (disabled) -> correct

where a is the indexed column and b is not. So as soon as anything is
actually requested from the relation, attrs_used is non-empty, the subset
test does its job and the path is rejected -- which lines up with the
empty-set reading of check_index_only() that the three of us arrived at
separately.

EXISTS seems worth noting because it shows up in ordinary code through
semi-joins, without anyone writing count(*).

The attached tarball includes that script as alcance.sql.

Happy to test a patch on both branches.