Haolin Wang

> Commit [258ec96](https://github.com/greenplum-db/gpdb/commit/258ec966b26929430fc5dc9f6e6fe09854644302) changed the format version to `AORelationVersion_PG12`, so only tables with this format version should enable index-only scan using the above logic. So, tables in-place upgraded from GPDB6->GPDB7...

> 1. Inject code to estimate_rel_size() which seems the only place where could(or already) call GetFileSegInfo() to get the formatversion in the planer layer, then the later paths selection might...

> > Also, lets make sure to update [README](https://github.com/greenplum-db/gpdb/blob/main/src/backend/access/appendonly/README.md) with all the design for this feature > > Yes, let's create a section in the readme titled "Index Only Scan",...

> * We talked about borrowing some of the code or creating similar function to `blkdir_entry_exists`, which was introduced for uniqueness checks. We can't directly use it since it assumes...

@soumyadeep2007 Let's move forward :-). I think the [pg_appendonly](https://github.com/greenplum-db/gpdb/pull/15063) part should be ready to merge. Next, I'm going to work on block directory refactor. Some questions come up after reviewing...

> Yes, but if you see IndexOnlyNext(), we call index_beginscan() which calls table_index_fetch_begin() and so on. So I wanted to add table_index_fetch_tuple_visible() to that family by keeping the table_index_fetch prefix....

I think I have addressed most of the previous comments, mainly including: - ban plan based on pg_appendonly.version - refactor indexonlyscan tableam based on `blkdir_entry_exists` Please continue to review, thanks....

Close the issue as a quick fix https://github.com/greenplum-db/gpdb/pull/15035 was merged.

Reopened as someone does hit a similar issue now.

For more info, after offline discussed with @kainwen (thank your for RCA for this hard issue), it can be sure that I hit the same case on `xmax`. Also pasted...